一般に、DDD の観点からはシナリオが間違っているため、(禅の意味で) Muと答えたくなる。DDD では、ビジネス要件とドメインの専門家から始め、それらからドメイン モデルを導き出します。
これは物議を醸すポイントですが、データベースはビジネス要件の付随的な成果物にすぎません (ほとんどの場合、エンティティを永続化する必要があると述べられています)。
とは言え、頑張ります。
ほとんどの場合、注文は非常に重要なビジネス オブジェクトであり、当然のことながら、各行の製品を含む注文行について知る必要があるため、注文行 (Order_Detail) から製品への関連付けが必要なように思われます。
ただし、特定の製品が与えられた場合、それがどの注文に含まれていたかを知る必要はほとんどないため、それは一方通行の関係を示唆しています。オーダー ラインから製品へはナビゲートできますが、製品からオーダー ラインへはナビゲートできません。
ただし、上記の分析は、より深いレベルでは誤りであることが判明する可能性があります。開発者とドメイン エキスパートの間の次の会話を想像してください。
開発者: 特定の注文の製品に関するすべてを常に把握できるように、注文から製品へのこの関連付けを作成しました。
Exp: それは良さそうですが、サプライヤーはどうですか?
Dev: それも含まれています。
Exp: では、製品のサプライヤーを変更するとどうなりますか?
Dev: それは受注データにも暗黙のうちに反映されます.
Exp: それは私たちが望むものではありません。出荷時の注文をデータに反映させたいと考えています。
この場合、実際にはデータベース スキーマにエラーがあることがわかります。ビジネス分析者は、さまざまなサプライヤーが収益にどのように影響するかについてレポートを実行する必要があるため、問題はレポートによって引き起こされる可能性があります (私が知っていること)。
このような場合は、注文明細行から製品への関連付けを完全に切断することをお勧めします。注文には、現在の製品データではなく、過去の (スナップショット) 製品データを保持する必要があります。
ドメインモデルでこれをモデル化するために、エンティティを意味的に反映するProductSnapshot 値オブジェクトを導入することさえできます。Product
Order全体として、それ自体と注文明細 ( を使用) の集合体としてモデル化することがますます合理的に思えますProductSnapShotsが、注文と顧客の関係はどうでしょうか?
現在、関連付けと集計を理解しているので、関連付けは集計を定義します。注文があった場合、顧客について知りたいですか？最も可能性が高い。与えられた顧客について、注文について知りたいですか? おそらく。
Customerこれは、Aggregate Rootを作成する双方向の関係を示唆しています。これはCustomerRepository、 があっても がないことを意味しますOrderRepository。Order が必要になるたびに、 経由で取得する必要がありますCustomer。
場合によっては、これは完全に理にかなっていますが、他の状況では非常に扱いにくい場合があります。それは本当にビジネス要件に依存します...
も作成することを検討するかもしれませんが、それは集約ルートOrderRepositoryに侵入します。Customerそんなことをしたら、教団の責任がどこにあるのか曖昧になってしまう。Order から Customer に移動するとどうなりますか? Customer注文のリストがありますが、から注文を読み取ると、それらはすべてメモリに取り込まれますOrderRepositoryか?
おそらくそうではありませんが、CustomerRepository. ここでのポイントは、Aggregate Rootsの分析が重要であり、Aggregate を定義したら、それに固執し、それを尊重する必要があるということです。
そのため、大きな集計よりも小さな集計を優先するため、この例では、集計を とその注文明細行に制約し、と の間にOrder関連性を持たないようにします。OrderCustomer
と の間に正式な関連付けがないからといって、それらをまったく関連付けることができないわけではありませんが、特定の Customer のすべての注文を提供するには、明示的なサービスがOrder必要です。ある場所から別の場所に移動することはできません。Customer
