ドメイン駆動設計（DDD） - 業務の言葉でソフトウェアを設計する | 仕組み解説

ドメイン駆動設計（DDD）は、業務の理解を中心に、重要なルールをモデルとコードへ反映する設計アプローチです。

業務担当者と開発者がユビキタス言語を揃え、Entity、Value Object、Aggregateへ業務ルールを反映し、Repositoryで保存するDDDの流れと、全パターンが必須ではないことを示す図

Domain Modelと言葉

Domain Modelは、注文や契約などの概念と業務ルールを表します。DBテーブルの写しではありません。

業務担当者と開発者は、会話、仕様、コードで同じユビキタス言語を使います。「注文を確定する」なら、コードでもconfirmOrderと表します。

Aggregate（集約）は、同時に整合性を守るモデルのまとまりです。外部からの変更はAggregate Rootを通します。

Order（Root）
├─ OrderLine
└─ ShippingAddress

「確定済み注文には明細を追加できない」というルールはOrderが守ります。

「同じトランザクションで守るルール」を基準に集約を決めます。

モデルと言葉が一貫する範囲をBounded Contextと呼びます。

境界の見つけ方とContext Mapは境界づけられたコンテキストで詳しく説明します。

DDDは、例外や状態遷移など、業務の複雑さが中心課題の場合に役立ちます。

重要な言葉とルールをコードへ置くところから始めます。全パターンの採用は目的ではありません。技術から隔離する構成はクリーンアーキテクチャで扱います。