私は関連するように見える2つの他の質問を見てきました：彼らは私の状況とまったく同じではありませんよしかしDDD |階層（同じタイプ）|制約
- Is Aggregate Root with Deep Hierarchy appropriate in DDD?
- How to define DDD Aggregate root for hierarchical data structure?
。おそらく "制約"の側面を失っています。
私の状況：私は "Study"という名前のARを持っていて、調査はクラスタ別に整理することができます（調査ドメインのクラスタリングサンプリング概念から借用）。
この "Study"では、このパラメータ "clusteringDepth"（整数）がコンストラクタであるとします。 3つを指定します（州、郡、都市）。
これは単なる仕様です。研究のあなたが実際に研究を行うときは、Studyに基づいてStudyPlanのインスタンスを作成します。
この場合、地方（第1レベルのクラスター）のリストを持つStudyPlanのインスタンスがあります。各州には郡（第2レベルのクラスター）のリストがあり、各郡には都市のリスト（第3 /最終レベルのクラスター）があります。
各クラスタには、クォータ情報と日付範囲（そのクラスタで作成する必要があるインタビューの数とインタビューの日付間隔を指定できます）を添付できます。明らかに、親クラスターは、 "子クラスターのクォータの合計がこのクラスターのクォータ以下でなければならない"のようにインバリアントを維持する必要があります。
Ok ...、今、制約：回答者とのインタビューを計画できます。そのためには、InterviewPlanのインスタンスを作成します。しかし、このインタビュープランは、ターミナル（第3レベル）クラスタにのみ接続できます。
もちろん、その制約を実装するのは簡単です（たとえば、クラスターのaddInterviewPlanメソッドで、クラスターが親かどうかをチェックします）。
...何らかの理由で...私はこれが良いDDDデザインではないと思います。その制約はあまりにも技術的に聞こえる。それは正常なドメインの会話で自然に行かない。
私の質問：DDDの「言語流動性/自然性要件」を過度に解釈していますか？または...私は概念を欠いていますか？私は、別のドメインモデル、何か、それはクラスタの子になることができ、インタビュープランを関連付けることができますか？
おかげで、関連する他の ラカ
：http://git.net/ml/programming.domain-driven-design/2006-06/msg00028.html
テーブル、インデックス、列、行、IDは、機能などのようなtehnical事を意味するものではありますが、クラスタリングを発明したのか、ドメインの専門家があなたのことを教えてくれたのですか？ – plalx