ドメイン駆動型設計におけるルートアグリゲートの問題

Question

私は2つのエンティティパブリッシャーとSocialAccountを持っています。どちらも独立しており、多対多の関係を持っています。両方ともルート集合体ですので、パブリッシャーからソーシャルアカウントを取得することができません。また、MからMへの関係を1からMに変換したいので、別のエンティティ登録を導入しました。{PubID、SocID、CreateDate}になります。これで、PublisherとRegistrationの間に1対Mの関係があり、RegistrationとSocialAccountの間に1対1の関係があります。 {;セット;取得}ので、出版社は

一覧<登録> _Registrationsを持つことになります

しかし、私は集約境界線を作成するときに、出版社は私のルートであると集計原理に従って、唯一のルート集約は、参照を保持します別のルート集約に変換します。しかしここでは、登録は参照を保持します。

登録はソーシャルアカウントのエンティティに関連付けられているので、私は総計原則に違反しています。

Answer 1

集約コンセプトの使用は間違っているようです。実際には、集約内のオブジェクトは他の集約への参照を保持できます。ルールは外部オブジェクトであり、集約内の何かへの参照を保持できません。

登録オブジェクトでは、関連性を集約する集約を避けるために登録オブジェクトが作成されたようです。つまり、オブジェクトを作成するのはなぜではありません。実際にあなたのドメインに登録がある場合は、作成してモデル化してください。ドメインにない場合は、単にパスをたどるように追加しないでください。

登録が追加されていれば、それはパブリッシャーの一部であるため、ソーシャルアカウントへの参照を保持できないと言います。これはルールではありませんが、登録が突然パブリッシャー集計の一部になるのはもっと重要です。出版社が登録コレクションを持っているだけの美徳ですか？

集約は、状態と不変量を維持するための1つの単位として扱われるオブジェクトのグループです。関係の存在自体は、集団のメンバーシップを与えるものではありません。

しかし、もう反対側を見てください。ソーシャルアカウントの登録は1対1です。ソーシャルアカウントを削除しても、依然としてパブリッシャーとの登録があることは理にかなっていますか？そうでなければ、登録は実際には実際にはSocialAccount集約の一部です。そのため、オブジェクトとその関係が状態変更後も常に有効であることを保証するために、集合体を作成します。 SocialAccountを削除する状態の変更に、そのアカウントに関連付けられているすべての登録が削除されている場合は、そのルールを適用するために集計に含めることをお勧めします。

これで、実際には、「集計ルール」に違反しています.PublisherからSocialAccount集約の内部部分である登録、オブジェクトへの外部関係があります。

これらの概念は単なるルールではなく、理由があります。集約が実際に何を意味しているかを見直し、ルールが実際に何を言い、実際に何を意味し、なぜそれらが最初に存在するのかを理解する必要があります。次に、関係を再評価し、それに応じて定義を集計します。

Answer 2

まず、モデル内の参照をカプセル化するための抽象化が必要です。

AGGREGATEは、データの変更のための単位として扱われる関連オブジェクトのクラスタです。

各AGGREGATEには、ルートと境界があります。境界は、集約内にあるものを定義します。ルートは、AGGREGATEに含まれる単一の特定のENTITYです。境界内のオブジェクトは互いに参照を保持することができますが、外部オブジェクトが参照を保持できるAGGREGATEの唯一のメンバーです。ルート以外のENTITIESはローカルIDを持ちますが、外部オブジェクトがルートENTITYのコンテキストからそれを見ることができないため、そのIDはAGGREGATE内でのみ区別できる必要があります。

あなたはそれについてSsyphusをどう思いますか？