はじめに

最近遅ればせながらドメイン駆動設計を本格的に勉強しようと思い立ちました。

 

「ドメイン駆動設計」エンジニアの皆さんならば一度は聞いたことがあると思います。
ただ、あまりに抽象的で難解な言葉が多く、そのメリットを享受できずに途中であきらめた人も多い（自分も含む）のも事実です。
アプリケーションを実装する際に「何が問題」でどうすれば問題を最小化できるのか、という視点で考えていこうと思います。

ビジネスロジック

ドメイン駆動設計の本では必ず「ビジネスロジックをドメイン層に閉じ込める」と必ず出てきます。
まず、ビジネスロジックとは？が一番大事なのですが、なぜビジネスロジックが大事なのかというと以下が答えになると思います。

• 仕様変更が起きるのは、ほぼビジネスロジックの部分

• ドメイン（業務知識）の本質はビジネスロジックに詰まっている

仕様変更が発生したり、新メンバーがアサインしても、確認すべきコードの場所がすぐに特定でき、コードを読むことでドメイン（業務知識）が理解できます。
また必須になりつつあるAIエージェントとの意思疎通としても活用できそうです。
これは素晴らしいことで、ビジネスロジックが様々な場所に散らばっていると修正がバグを生むこともあるし、アサイン者がドメイン知識もおぼろげで実装すると、クライアントの意図した実装になっていないことが多々あります。
これらを解決してくれるのが、ドメイン駆動設計かと思っています。

エンジニアのビジネスへの理解が必須になる

この本は、エンジニアはビジネスへの深い理解をしなければならない、という本質をついてきます。これが一番難しい部分かと思います。
先ほども触れたAIエージェントとの意思疎通は、この部分を適切に指示できるかが鍵になり、実装の結果を確認する場合にもレビュアー側の負担を軽減してくれます。

【病院予約システムの例】

ビジネスロジック

• 1人の患者は同じ診療科で1日1回しか予約できない
  
• 初診は紹介状が必須（診療科による）
• 土曜日の午後は診察不可
• 医師のスケジュールに空きがなければ予約できない
• キャンセルは前日17時まで可能

問題と対処法

【クライアント（事業側）の視点】

「本質的な業務ルールが、ちゃんとソフトウェアに反映されているか？」
システム開発でよくある悩みの1つは、「言ったことと、実装されたものが違う」というすれ違いです。これは、業務知識（ドメイン）が正しく理解・整理されず、エンジニアの頭の中で都合よく「翻訳」されてしまうことで起きます。

DDD（ドメイン駆動設計）は、これを防ぐための考え方です。
DDDでは、以下のような価値が提供されます。

• 業務の言葉で会話できる（ユビキタス言語）
  　→ ビジネス用語とコードが一致するので、認識のズレが起きにくい
• 本質的なビジネスルールに集中できる
  　→ 複雑な業務処理を整理し、ルールが守られているか把握しやすくなる
• 仕様変更にも柔軟に対応できる構造
  　→ 小さな変更に大きなコストを払わずに済む設計になる

つまり、DDDを導入することで「業務の知識が資産として残る設計」が可能になり、ビジネスの変化に強いソフトウェアになります。

【エンジニア（開発側）の視点】

コードを「構造」で捉えることで、変更に強くなる
技術的な課題の多くは、以下のような「密結合」によって生じます。

• 複雑な分岐がコントローラやモデルに集中
• 表示・保存・通知などの処理が混ざり合っている
• バグの修正が新たなバグを呼ぶ

DDDは、これらを解決するために「責任の分離」と「ドメイン中心の設計」を強調します。
エンジニアにとってDDDは、以下のような効果をもたらします。

• ドメインの知識を明示的にモデル化できる
  　→ エンティティ・値オブジェクト・ドメインサービスなどで意味ごとに整理
• ユースケースごとに処理を独立させられる
  　→ Application層でのUseCaseやServiceクラスによって影響範囲が明確
• インフラ依存から自由になる
  　→ DBやメール送信などの実装がドメインに影響しにくくなる

結果として、壊れにくく・読みやすく・テストしやすいコードが実現されます。

両者が協力するための共通言語：ユビキタス言語

DDDでは、クライアントとエンジニアが同じ言葉を使って議論することが前提です（＝ユビキタス言語）。
こういったやり取りが自然にできれば、仕様の共有も、実装の説明もスムーズです。

【クライアントの会話例】

クライアント
この患者さん、小児科に予約が入ってるんですけど、もう高校生なんですよね。システムで防げますか？」
エンジニア
「はい、小児科は15歳までに限定して、それを超えている人は予約できないようにできますよ。」

【エンジニア同士（AIエージェント含む）の会話例】

エンジニア A
「Reservation の作成って、年齢制限とか紹介状要件とか全部 ReservationPolicyServiceで弾いてる感じ？」
エンジニア B
「そう。年齢は AgeRestriction、紹介状は IntroductionRequirementの値オブジェクトで、診療科ごとに設定してる。」

最後に：DDDは技術ではなく、コミュニケーションの設計

DDDは単なる設計パターンではありません。
それは「複雑な業務を理解し、ソフトウェアに適切に反映するためのアプローチ」です。

• クライアントにとっては：業務が正確に反映される安心感
• エンジニアにとっては：設計の理由と根拠が明確になる構造

その両者の橋渡しをするのが、DDDです。
ただ、実際に実装すると様々なところで疑問点が生じるのも事実です。
次回はその部分をブログにしていきたいと思います。