domain-driven-design - DDD で集計間の関連付けをどのように処理しますか?

Question

私はまだ DDD に頭を悩ませていますが、私が遭遇した障害の 1 つは、個別の集計間の関連付けを処理する方法にあります。Customers をカプセル化する 1 つの集約と、Shipments をカプセル化する別の集約があるとします。

ビジネス上の理由から、Shipments は独自の集計ですが、顧客に明示的に関連付ける必要があります。私の顧客ドメイン エンティティには、出荷のリストが必要ですか? もしそうなら、リポジトリ レベルでこのリストを作成するにはどうすればよいですか? CustomerRepository と ShipmentRepository (集約ごとに 1 つのリポジトリ) があるとします。

「関係」ではなく「関連」と言っているのは、これがインフラストラクチャの決定ではなくドメインの決定であることを強調したいからです。最初にモデルからシステムを設計しています。

編集：テーブルをオブジェクトに直接モデル化する必要がないことはわかっています-それが、最初にモデルを設計している理由です。この時点では、データベースについてはまったく気にしません。これら 2 つの集計間の関連付けだけです。

Answer 1

ShipmentRepository が顧客データを出荷モデルに集約できない理由はありません。リポジトリは、テーブルとの 1 対 1 のマッピングを持つ必要はありません。

複数のテーブルを単一のドメイン モデルに結合するリポジトリがいくつかあります。

Answer 2

この質問に答えるには2つのレベルがあると思います。あるレベルでは、問題は、顧客と出荷の関係をどのように設定するかです。私は、出荷リポジトリにfillOrders（List Customers、....）を含めることができる「fill」セマンティクスが本当に好きです。

もう1つのレベルは、「DDDの一部である非正規化ドメインモデルをどのように処理するか」です。そして、「顧客」はおそらくそれらすべての最良の例です。なぜなら、それは非常に多くの異なるコンテキストで単に現れるからです。ほとんどすべてのプロセスには顧客が含まれており、顧客のコンテキストは通常​​非常に多様です。最大で半分の時間であなたは「注文」に興味を持っています。開始時にドメインの理解が完全であった場合、顧客ドメインの概念を作成することは決してありません。しかし、そうではないので、私は常にCustomerオブジェクトを作成することになります。3年後、適切な「顧客」ドメインモデルを作成できたと感じたプロジェクトを今でも覚えています。私は顧客を代表する代替のより詳細な概念を探しています。PotentialCustomer、OrderingCustomer、CustomerWithOrders、およびおそらく他のいくつか。申し訳ありませんが、名前は良くありません。そのためにはもう少し時間が必要です;）

Answer 3

出荷には、顧客との多対 1 の関係があります。クライアントの出荷を探している場合は、クライアント パラメータを取得するクエリを出荷リポジトリに追加します。

一般に、多面が制限されていない場合、エンティティ間に 1 対 1 の関連付けを作成しません。