これまでの記事

この記事は以下の記事の続編となります。

基幹システム移行で得たDDDの本質体験

これまでの記事で、基幹システム移行プロジェクトにおける私のDDD（ドメイン駆動設計）実践体験について、その背景と開発がスムーズに進んだ理由をお話ししてきました。

今回は、前回書ききれなかった「読みやすいコード」に関する内容です。

どうしても長文になってしまいました。お急ぎの方は以下の要約をご確認ください。

DDDが提供する可読性向上へのアプローチとして、以下の3点を挙げます。

1.コードが「業務の物語」を語る
  ユビキタス言語をコードに直接反映することで、業務シナリオを読むように直感的に処理を把握できる。

2.メインフローと詳細の分離
  責務分離とカプセル化により、全体像を把握しやすくし、読みやすくします。

3.整合性が保たれた状態
  集約を用いて不変条件を維持することで、データの整合性を気にする必要がなくなり、読みやすくなります。

「脳に収まるコード」の重要性

DDDの話の前に、コードの読みやすさの話題を考えるときに、影響を受けた書籍をご紹介します。
それが、Mark Seemann氏の著書『脳に収まるコードの書き方―複雑さを避け持続可能にするための経験則とテクニック』（2024年6月）です。

書籍の中では、人間の認知特性を考慮し、複雑なソフトウェアをいかに「脳に収まる」サイズと形に整理し、持続可能なコードとして維持していくかを詳細に解説しています。

人間の脳の特性を考慮すること、つまり「人間が一度に頭の中で理解し、推論し、記憶できる情報量には限りがある」という考え方は、ドメイン駆動設計（DDD）で語られる認知負荷や可読性といった読みやすさの議論にも深く通じると感じました。

DDDが提供する「読みやすさ」の3つの要素

DDDの手法を改めて振り返ると「読みやすさ＝可読性」への思いを感じました
認知負荷を低減し、読みやすさを維持することは、変更容易性にもつながります。

私が読みやすくなったと実感した場面と、DDD手法を紐づけて理解することで、抽象的であったDDDの理解につながると考えましたので、以下に3つの要素を挙げていきます。

1. コードが「業務の物語」を語る（ユビキタス言語の直接的な反映）

課題

従来のコードでは、例えば英数字固定長や連番で構成されたDBのカラム名など、技術的な都合に引きずられた命名が多く、コードから業務内容を読み解くのが困難でした。DBスキーマや画面仕様書と何度も照らし合わせる必要があり、理解に高い認知負荷がかかっていました。

DDDによる解決

クラス名、メソッド名、変数名、エラーメッセージに至るまで、ドメインエキスパートと開発者が共有するユビキタス言語でコードを記述します。
例えば、order.IsShippable()（注文が出荷可能か判定）やcustomer.ApplyDiscount(discountPolicy)（顧客に割引ポリシーを適用）のように、コードが業務の行動や概念を直接的に表現するため、業務シナリオを読むように処理を把握できます。

2. メインフローと詳細の分離（責務分離とカプセル化）

課題

従来のコードでは、複雑な条件分岐（if-elseのネスト）やデータ変換・整形処理が混在していました。ループが多重に処理され、条件に応じて処理が切り替わり、途中で終了することもあり、処理の流れを脳内で記憶しながら整理する必要がありました。

DDDによる解決

複雑な条件判断や汎用的なユーティリティ処理は「隅っこ」として、プライベートメソッドや専用の小クラスにカプセル化します。結果的に業務の「大きな流れ（フロー）」がメインのメソッドやクラスに残る形へ整えていきます。
これにより、開発者は全体の流れを把握してから、必要に応じて詳細なロジックを掘り下げて確認できるため、一度に理解すべき情報量が適切に制御され、認知負荷が大幅に軽減されます。

3. 整合性が保たれた状態（集約による不変条件の維持）

課題

従来のコードでは、複数のテーブルやオブジェクトにまたがるデータが個別に操作される可能性があり、「正しく処理されているか？」「この値が不正だったらどうなるだろう？」と常にデータの整合性を脳内で処理する必要がありました。

DDDによる解決

集約という概念により、常に一貫したビジネス上の状態を保つべきオブジェクトのまとまりを作ります。集約ルートを通じてのみ操作を許可することで、ビジネスルール（不変条件）が強制されるため、コードを読む際に「このオブジェクトは常にビジネス上、有効な状態である」という信頼性が高まります。これにより、データの整合性を疑う認知負荷から解放されます。

DDDはパラダイムシフトでした

従来の開発において、私は DBのテーブル構造をクラスにマッピングして「そのまま扱うこと」を重視していました。DBのテーブルを常に意識してコードを読むことが当たり前だったのです。
しかし、DDDを通じて「複雑な業務ロジックのコードを読みやすくするため、構造を変えてよい」という考え方へと転換したのです。この価値観と優先順位の転換が、結果として可読性と保守性を劇的に向上させました。

このように私にとって、DDDは「業務ロジックの文脈を、業務の言葉で記された物語のようにする」というパラダイムシフトでした。

今後の展望

私は今後、入出力がシンプルな部分から、小さくDDDを始めてみることを考えています。
例えば、SQLの話で言うとFETCHを多用しなければ実装できなかった「複雑な業務ロジック」を含むストアドプロシージャなどは、取り組みやすい課題です。

私の経験を通じて得られた知見が、あなたのシステム開発の参考になれば幸いです。