現場で役立つシステム設計の原則から学んだDDD実践知識

増田亨「現場で役立つシステム設計の原則」とVaughn Vernon「実践ドメイン駆動設計」を読んで、特に重要だと感じた概念とルールをまとめた。

DDDはなぜ必要か

ソフトウェアが失敗する原因の大半は、技術的な問題ではなく業務の理解不足にある。

これらは、コードが現実のビジネスを正確に反映できていないから起きる。

DDDが解決しようとするのは、ソフトウェアの中心に「業務（ドメイン）」を置くことだ。

従来の発想：
  要件定義 → DB設計 → API設計 → 実装

DDDの発想：
  ドメインを理解する → ドメインモデルを設計する → それをコードに写す

ただしDDDはすべてのプロジェクトに向かない。業務ロジックが複雑な場合にのみ真価が出る。単純なCRUDシステムでは過剰設計になる。

ドメインエキスパート（業務担当者）と開発者が共同で作り上げ、会話・ドキュメント・コードのあらゆる場面で一貫して使い続ける共通言語のこと。

ドメインエキスパートは「契約」「顧客」「請求」という言葉で話す。開発者は「Contractテーブル」「Userレコード」「Invoiceオブジェクト」という言葉で話す。この翻訳コストが要件の誤解とモデルの乖離を引き起こす。

ユビキタス言語を確立することで、ドメインモデルが業務の言葉で直接表現され、翻訳コストがゼロになる。

実践として：

注意点として、ユビキタス言語は境界づけられたコンテキストの中でのみ一貫性が保証される。

特定のドメインモデルが適用される明示的な境界。境界の内部では：

境界の外では同じ言葉が異なる意味を持つことがある。例えば「顧客」は販売コンテキストでは「購入者」、サポートコンテキストでは「チケットを上げる人」を意味しうる。

単一の巨大なドメインモデルを全システムで共有しようとすると、モデルが膨大な概念を抱え込み、チーム間の変更が互いに影響し合いリリースが困難になる。Bounded Contextを明示的に設けることで、各チームが自律的にモデルを進化させられる。

マイクロサービスの境界を決める際の目安は「1コンテキスト≒1サービス」。

業務に関するロジック（計算・判断・状態遷移）を、データを保持するドメインオブジェクト自身に持たせる設計方針。

サービス層やコントローラーに業務ロジックが漏れ出す「ドメインモデル貧血症（Anemic Domain Model）」を避ける。

「この計算はどこに書くべきか」と迷ったときは、計算の対象となるデータを持つオブジェクトに書く。

新機能・新システムの設計開始時は、DBスキーマやAPIの設計より先に業務の言葉・ルール・概念を整理する。「どのテーブルを作るか」ではなく「業務ではどんな概念が動いているか」から問いを始める。

DBやAPIから設計を始めると：

例外：純粋なCRUDシステム（業務ロジックがほぼない）ではDBスキーマ中心でも問題ない。

業務上の計算・判断・バリデーションは、そのデータを保有するドメインオブジェクトのメソッドとして実装する。サービス層（ApplicationService / UseCase）は「誰を呼ぶか」のオーケストレーションのみとし、業務判断を持たない。

サービス層に業務ロジックを書くと：

例外：複数の集約をまたぐ処理（例：注文と在庫の整合性）は、特定のドメインオブジェクトに属さないためサービス層に置く。ただしその場合も各集約のドメインオブジェクトへできる限り委譲する。