DDD（ドメイン駆動設計） とは？

たとえば注文を扱うなら、「いつ注文が成立するか」「取消できるのはいつか」といった業務の意味やルールから考えるよ。業務の専門家と開発者が一緒に、ソフトウェアで扱うモデルを作り、理解が深まれば見直すんだ。

命名は一部だよ。たとえば「確定した注文はこう扱う」と意味や振る舞いもそろえる。その共通の言葉をユビキタス言語というんだ。会話・モデル・コードが食い違っていないか、日々確かめることが大切だね。

同じ「商品」でも、注文管理では購入時の価格、在庫管理では保管場所や数量に注目するかもしれない。意味やモデルが一貫する範囲を、境界づけられたコンテキストとして明示するよ。境界の間でどう情報をやり取りするかも設計するんだ。

エンティティは同一性で追跡するもの。注文番号で同じ注文を見分けるのが一例だよ。値オブジェクトは、内容の値で扱うもの。たとえば金額と通貨の組を表せる。住所も値として扱う場合があるけれど、業務によっては同一性が重要なエンティティになるんだ。

集約は整合性を守る単位としてまとめたモデルで、集約ルートを通して変更するよ。たとえば注文とその明細を扱う場合、数量などのルールを守る。リポジトリは集約を取得・保存する窓口のパターンで、Gitのリポジトリとは別だね。全部を機械的に使うのではなく、業務の複雑さに合わせて選ぶんだ。

別々の考え方だよ。コンテキストは言葉とモデルの境界で、必ず一つの独立サービスにする決まりではない。戦略的な境界の設計と、モデル内の戦術的なパターンを組み合わせる。単純なCRUDにまで複雑な実装を足す必要はなく、目的とコストに合わせよう。