はい、DDD では深い階層は問題ありません。
非常に広範な集計になっても問題ありませんか? - 現実がそれほど複雑であり、ドメイン モデルが可能な限り最高のものである場合、複雑な集約ルートになってしまいます。
はい、Form
集約ルートにする必要があります。
他のすべてのオブジェクトは値オブジェクトである必要があります-間違っています。他のすべてのオブジェクトは、それらを取得するためのリポジトリなしで、非集約ルート エンティティ (ID 付き) である必要があります。値オブジェクトには ID がありません。値オブジェクトの等価性は、ID の等価性ではなく、その属性値によってのみ決定されます (詳細はこちら)。
この場合、FormRepository は子オブジェクトのあらゆる種類の CRUD メソッドで雑然とします。いいえ、リポジトリには集約ルートに関するメソッドのみを含める必要があります。つまりGet<T> , Save<T> where T : IAggregateRoot
、集約ルートのインスタンスを取得したら、属性とメソッドを介してトラバースして取得できます。何が必要。例:
var formId = 23;
var form = _formRepository.Get(formId);
var firstGroup = form.Sections.First().Group().First();
またはそれ以上
var groupIndex = 1;
var firstGroup = form.GetGroupAt(groupIndex);
どこ
public Group GetGroupAt(int groupIndex)
{
Sections.First().Group().ElementAt(groupIndex);
}
このような表現は簡単にパフォーマンスの問題につながる可能性があると思います.CQRSを使用すると、コマンドハンドラーからドメインメソッドを呼び出すことForm
になり、エンティティの永続化にNHibernateを使用すると、デフォルトで遅延読み込みが使用されForm
、DBからのみ読み込まれます. 、そして実際に触れるエンティティのみをロードするため、たとえばSections.First()
、DB からすべてのセクションをロードしますが、グループや残りはロードしません。クエリを実行するには、FormDto
(データ転送オブジェクト) とその他のフラット化された dto を作成して、必要な形式でデータを取得します (エンティティ構造とは異なる可能性があり、UI が dto 構造を駆動する可能性があります)。DDD/CQRS/NHibernate/Repository に関する情報については、私のブログをご覧ください。