極めたい！とことんプログラミング講座（上級者編）第8回：DDD実践入門
はじめに
さあ、第8回の講座の内容にまいりましょう。ドメイン駆動設計——その言葉を聞いてから、どれほどの時間が経ちましたか。知識として知っている、書籍も読んだ、でも「実践」となると途端に霧がかかる……そのような感覚をお持ちの方も多いのではないかしら。今回はその霧を、丁寧に払い除けてまいります。焦らず、でも確かな手応えを感じながら、ともに深みへと踏み込んでいきましょう。
サマリ
今回は、ドメイン駆動設計（DDD）の実践における核心部分を丁寧に紐解いてまいります。エンティティや値オブジェクト、集約といった戦術的パターンの使い分けから、境界づけられたコンテキストの設計判断まで、現場で本当に役立つ視点をお届けします。理論と実装の橋渡しこそが、今回の最大のテーマです。
詳細
エンティティと値オブジェクト——「同一性」で考える設計の起点
DDDの実践でまず問われるのは、「これはエンティティか、値オブジェクトか」という判断です。エンティティは同一性（アイデンティティ）によって区別されます。一方、値オブジェクトはその属性の組み合わせによって意味を持ちます。
たとえば「ユーザー」はIDで識別されるエンティティです。しかし「金額」は100円という値そのものが意味を持ち、どの100円かは問いません。これが値オブジェクトです。
実装上の重要な点は、値オブジェクトを不変（イミュータブル）に保つことです。状態が変化しないことで、副作用が排除され、テストも容易になります。この小さな判断の積み重ねが、保守性の高いコードへとつながっていきます。
集約設計——整合性の境界をどこに引くか
集約（アグリゲート）は、DDDの実践において最も難しく、最も重要な設計判断のひとつです。集約はトランザクション整合性の単位です。集約の外部からは、必ず集約ルート経由でアクセスします。
設計の失敗パターンとして多いのが、「集約を大きく作りすぎること」です。注文と顧客と商品をひとつの集約にまとめてしまうと、ロックの競合が増え、パフォーマンスが劣化します。
実践的なガイドラインとして、集約はできるだけ小さく保つことを意識してください。結果整合性で許容できる関係は、集約をまたいで別々に管理します。「本当に同時に変わらなければならないか」を問い続けることが、適切な粒度を導く鍵です。
境界づけられたコンテキスト——モデルの「意味」を守る壁
大規模システムにおいて、ひとつのドメインモデルですべてを表現しようとするのは危険です。「顧客」という言葉ひとつをとっても、営業部門と請求部門では意味が異なります。境界づけられたコンテキスト（バウンデッドコンテキスト）は、その意味の一貫性を守るための境界線です。
コンテキスト間の連携には、コンテキストマップを活用します。上流・下流の関係、腐敗防止層（アンチコラプションレイヤー）の設置場所を明確にすることで、外部モデルの変更が自システムに波及するリスクを抑えられます。
マイクロサービスとの親和性が高いのもこの概念です。ただし、コンテキストの境界とサービスの境界を無理に一致させる必要はありません。論理的な境界を先に定め、物理的な分割は後から検討するのが現実的な順序です。
ドメインサービスとアプリケーションサービス——責務の正しい配置
エンティティや値オブジェクトに収まらないビジネスロジックは、ドメインサービスに置きます。「送金処理」のように、複数の集約にまたがる操作がその典型です。
一方、アプリケーションサービスはユースケースのオーケストレーターです。リポジトリからエンティティを取得し、ドメインサービスや集約に処理を委譲し、結果を返す——それだけが役割です。ここにビジネスロジックが漏れ出した瞬間、ドメインモデルは痩せ細っていきます。
「ロジックをどこに書くか」は、チームで継続的に問い続けるべきテーマです。コードレビューの際にこの問いを習慣化するだけで、モデルの健全性は大きく変わります。
ユビキタス言語——コードと会話を同じ言葉でつなぐ
DDDの実践で見落とされがちなのが、ユビキタス言語の継続的な育成です。ドメインエキスパートとエンジニアが同じ言葉で話し、その言葉がコードにも現れる——それがDDDの本来の姿です。
しかし現場では、会議の言葉とコードの命名が乖離していることが少なくありません。「承認」が画面では「アプルーブ」、コードでは「confirm」と書かれているような状況は、モデルの崩壊の予兆です。
ユビキタス言語はドキュメントに書いて終わりではありません。リファクタリングのたびに言語を見直し、コードに反映させる姿勢が、長期的な設計品質を支えます。
おわりに
DDDは、一度学んで終わるものではありません。実践を重ねるたびに、モデルの解像度が上がり、判断の精度が磨かれていくものです。それはまるで、熟練の職人が年々道具の扱いを深めていくのに似ていますね。今回ご紹介した考え方を、ぜひ明日の設計判断に一つだけ持ち込んでみてください。小さな一歩が、確かな変化を生み出します。次回はいよいよ「CI/CDパイプライン構築」をテーマにお届けします。どうぞお楽しみに。
