domain-driven-design - DDDモデリング、集約ルート間の相互作用

Question

集約ルートを1;2;3でマークしました。とても素敵に見えます-ほとんどブドウのようです。

私が嫌いなものは、赤い矢印でマークされたエンティティです。

それを想像してみましょう：

• AR＃1は会社です
• AR＃2はオフィスです
• AR＃3は従業員です
• 赤い矢印でマークされたエンティティの名前はCountry
  • 会社は、従業員を雇用する国のルールを設定します（雇用に関してcompany.Countries.Contains(employee.Country)は真実でなければなりません）

私はどういうわけか、ドメインのこの非常に重要でない部分を見て（おそらくこの例ではそのように聞こえないかもしれません）、Countryを集約ルートに昇格させることは避けたいと思います。

骨材の根に関する用語集は次のように述べています。

内部メンバーへの一時的な参照は、単一の操作内でのみ使用するために渡すことができます。

つまり、「EmployeeCountry」のようなものを導入し、会社の国への参照を削除し、従業員の国が雇用業務でどの会社の国とも一致するかどうかを確認することは合理的に聞こえますか？

他のアイデアはありますか？

どうすればブドウを本来のように見せることができますか？

Answer 1

このコンテキストでCountryは、単なる値オブジェクトであり、エンティティではなく、ましてや集約ルートであるため、設計について何も変更する理由はありません（詳細情報がない場合）。

さらに、引用する警告は、集合体自体ではなく、集合体ルートの内部メンバーに関係することに注意してください。複数の場所で集計への参照を維持することに問題はありません。集約ルートは子オブジェクトをカプセル化することになっているため、関連オブジェクトにビジネスルールを適用する場所は1つです。

これは、エバンスの「ドメイン駆動設計」（別名「ブルーブック」）のいくつかの場所ではっきりと見ることができます。たとえば、127ページの図（アグリゲートルートの概要）を参照してください。この図は、エンジンアグリゲートへの参照を持つCarアグリゲートを示しています。