次のシナリオで本当に苦労しています。
ユーザー集約があるとしましょう。ユーザーは 1 つ以上のグループ、メッセージ、友達、写真ギャラリーなどを作成できます。今では、グループ、メッセージ、友達、写真ギャラリーはそれぞれ独自の集約グループにある必要があるようです。グループ、メッセージ、友人、フォト ギャラリーなどの User プロパティを持つだけでなく、これらのセクションのそれぞれに IList<> プロパティを含むユーザー エンティティを作成するのは非論理的です。どのアプローチが DDD から最も理にかなっていますか?視点？エンティティのハイドレーションについても考えており、ユーザー エンティティからすべてを取得するのではなく、必要に応じてグループやメッセージなどを取得する方が理にかなっているようです。このシナリオを処理するための推奨される方法は何ですか?
特定のビジネス ドメインについてよく知らなくても、Userクラスを一種の神の集合体とし、その下に他のすべてのものを集約するのは非常に間違っているように思えます。
集約ルートを使用してエンティティをより大きなエンティティにグループ化するかどうかは、ビジネスの仕組み次第です。たとえば、その下にPhotoGallery多くのPhotoオブジェクトがある集約ルート、またはその両方PhotoGalleryであり、Photo両方とも別個の集約ルートである可能性があります。
たとえば、写真を常に収集、処理、処理する写真現像会社を経営しているとしますPhotoGallery(1 つの集約ルート)。
Photoまたは、ギャラリー全体 (2 つの集約ルート) をロードする必要なく、共有して一般的に使用できるソーシャル ネットワーキング サイトを運営している場合があります。
したがって、それは本当にあなた次第であり、あなたのビジネスドメインが決定するものです. いつでも試してみて、物事を 1 つの方法で試してみて、それがどうなるかを確認してから、後でリファクタリングすることができます。