深層階層を持つ集約ルートがDDDに適していますか？

Question

私は、ユーザーが質問にフォームで回答するシステムを持っています。私はこのモデルを表現するオブジェクトを持っていますが、これらのオブジェクトをDDDの観点からどのように整理するかについてはあまりよく分かりません。

1. フォーム（独自のリストがあります）。
2. セクション - >（独自のリストを持ちます）グループ;
3. グループ - >（独自のリストを持つ）質問;
4. 質問 - >（サブ質問の独自のリストを持つことができます）質問;
5. 質問 - >（それ自身のリストを持っています）回答;
6. Answer - >（それ自身のリストを持っています）Answer_Details;
7. Answer_Detail - >（潜在的に独自のサブ詳細のリストがあります）Sub_Answer_Details。

すべてのオブジェクトは15以上のプロパティを持ち、それぞれが親なしでは意味をなさない。 DDDによると、フォームエンティティは集合ルートでなければならず、他のすべてのオブジェクトは値オブジェクトである必要があります。つまり、私はフォームエンティティのためだけにリポジトリが必要です。この場合、FormRepositoryは子オブジェクトのすべての種類のCRUDメソッドで複雑になります。私の推論はDDDの観点から正しいのですか？それは大丈夫ですか？そのような表現は簡単にパフォーマンスの問題につながると私は信じている。

Answer 1

はい、深い階層はDDDで問題ありません。

これは大丈夫ですか？非常に広範な集計になりますか？ - 現実が複雑で、あなたのドメインモデルがあなたが把握できるほど最善であれば、複雑な集約ルートになります。

はい、Formは、集約ルートである必要があります。

他のすべてのオブジェクトは値オブジェクトでなければなりません。間違っていれば、他のすべてのオブジェクトはリポジトリなしでIDを持つ非集約ルートエンティティでなければなりません。 ValueオブジェクトにはIdがありません。値オブジェクトの等価性は、Idの等価性ではなく、その属性値によってのみ決定されます（詳細はhere）。いいえ、リポジトリは、集約ルートに関するメソッドのみが含まれている必要があり、すなわちGet<T> , Save<T> where T : IAggregateRoot、あなたが集約ルートのインスタンスを取得したら、することができます - FormRepositoryはオブジェクトの子供のためのCRUDメソッドのすべての種類でいっぱいになります。この場合

あなたが必要とするものを得るための属性とメソッドを介してトラバースします。例：

var formId = 23; 
var form = _formRepository.Get(formId); 
var firstGroup = form.Sections.First().Group().First(); 

またはより良い私は、このような表現が簡単にパフォーマンスの問題につながることができると信じて

public Group GetGroupAt(int groupIndex) 
{ 
    Sections.First().Group().ElementAt(groupIndex); 
} 

var groupIndex = 1; 
var firstGroup = form.GetGroupAt(groupIndex); 

- あなたはCQRSを使用している場合、あなたはつもりいくつかのFormを呼び出すことドメインメソッドをコマンドハンドラから削除し、NHibernateをエンティティの永続化に使用すると、defaul遅延ロードを使用して、DBからFormしかロードせず、実際に触れるエンティティのみをロードするので、たとえばSections.First()はDBからすべてのセクションをロードしますが、グループと残りはロードしません。クエリを行うには、FormDto（データ転送オブジェクト）と他の平坦化されたdtosを作成して、必要な形式でデータを取得します（エンティティ構造と異なる場合があり、UIがdto構造を駆動する可能性があります）。答えは、私は私も私の2セントを追加することも考えられ受け入れられているにもかかわらず、DDD/CQRS/NHibernateは/リポジトリ

Answer 2

に関する情報のための私のblogを見ている：

深い階層は、（おそらく）細かいですが、集約の背後にあるアイデアは実際にこれを防ぐことであることに留意してください。私はのラインに沿って集計内のエンティティと考える傾向がある：

「このエンティティが ARずに何の意味を持っていますか？」

私にはコンテキストがありません。あなたのモデルはOrder/OrderLineです。 OrderLineにはOrderがないと意味がありますか？オーダーラインで何か（行動）を単独で行うことはできますか？ここでの明らかな答えは「いいえ」です。

各モデルは、コンテキストに基づいて処理する必要があります。しかし、の所有者は必ずしも封筒を意味するものではありません。

これらはあなたが提供される一つののBCはAnswerはそのQuestionなしでは意味を持たないことがあなたのケースでは

を:)修正取得する別の有界コンテキストで作業したときに表示する方が簡単かもしれません。しかし、QuestionはBCに住むことができ、特定の質問はExamination BCとEnrollment BCで使用できます。これらはすべてあなたの文脈に依存するように完全に構​​成されています。

したがって、QuestionがARの場合、Form ARが所有する質問は、単なるバリューオブジェクトまたは単純なQuestionIdであってもかまいません。