DDD：ルートアグリゲートが別のルートアグリゲートへの参照を保持するのは正しいですか？

ドメイン駆動型設計（DDD）に従う場合、たまたま別のアグリゲートのルートエンティティである内部エンティティへの参照をルートアグリゲートが保持するのは正しいですか？

私はこれが正しいとは思わない、主にブルーブックのこのルールのため：

AGGREGATE境界の外側にあるものは、ルートENTITYを除き、内側にあるものへの参照を保持できません。ルートENTITYは、内部ENTITIESへの参照を他のオブジェクトに渡すことができますが、それらのオブジェクトは一時的にのみそれらを使用でき、参照を保持することはできません。ルートはVALUE OBJECTのコピーを別のオブジェクトに渡すことができますが、それがどうなるかは問題ではありません。これは単なるVALUEであり、AGGREGATEとの関連付けがなくなるためです。

ルートアグリゲートが別のルートアグリゲートへの参照を保持している場合、前者の境界に違反しており、アグリゲートの概念全体が破損しているため、ルートアグリゲートが別のルートアグリゲートへの参照を保持する必要があるように見える場合は、別のエンティティを作成するには、おそらく他のルートエンティティと同じメンバーの一部を共有しますが、この本の他のルールが示すように、グローバルアイデンティティはありません。

ルートエンティティにはグローバルアイデンティティがあります。境界内のエンティティには、AGGREGATE内でのみ一意のローカルIDがあります。

これは正しい方法だと思いますが、それは反復的で冗長であると感じるので（DDDのコンテキストを取り除いて、純粋なOOPで）、フィードバックを求めています。

あなたは本を過剰に解釈しているかもしれません。基本的には、Aggregateの外部にあるものは、ルート以外の内部にあるものへの参照を保持できません。したがって、ルートへの参照を保持することは正当です。ルートへの参照を保持することは、それが独自の集計の一部であり、その不変式を制御できることを意味しません。独自の不変条件と自律性を維持します。

しかしながら、

• 一般的に受け入れられているグッドプラクティスは、完全な参照ではなく、IDを保存することでARを参照することです。
• デザインを集約するためのより現代的なアプローチ（レッドブックを参照）は、集約間の明確な分離を提唱します。ビジネストランザクションは、単一の集計の状態のみを変更する必要があります。この仮定の下では、別の集合体への参照を保存する必要性は、2つの集合体を同時に変更することはないため、消える傾向があります。

ルートアグリゲートが別のアグリゲートのルートエンティティである内部エンティティへの参照を保持するのは正しいですか？

これは決して起こりません。値オブジェクトは複数の集合体の一部になることができますが、エンティティーになることはできません。その理由は、集約間で同じエンティティインスタンスを共有することを妨げるものは何もないからです。エンティティインスタンスEが集約インスタンスAとBの両方に属しているとしましょう。DDDの前提は、集約がエントリポイントであるため、Aをロードし、それを介してエンティティEを変更できます。 B（ロードしなかった）。

グレッグヤングの回答はこちら：http : //domain-driven-design.3010926.n2.nabble.com/Can-an-Entity-be-Shared-across-many-Aggregates-td7579277.html

集約ルートオブジェクトには、（通常）そのドメインの一部であるプロパティのみが必要です。

集約にないプロパティを持つARオブジェクトがある場合、すぐに問題に直面します。'何故なの？'

おそらく他のオブジェクトのIDを追加できますか？または、リポジトリを挿入しますか？

しかし、両方のルートオブジェクトを参照し、必要なロジックを実行するクロスドメインサービスを追加する必要があるようです