正しく集計ルートを集計する

Question

集計ルートの設計にはいくつかの問題があります。ここでは、私が店になりますさて、この私の集約ルートに基づいて、私の心:)

Store (the aggregate root) 
-> Sales - A store create a sale every day 
-> Zones - A store is divided into zones 
    -> Styles - A zone has x number of styles 
     --> Colors - A style has x number of colors 
    etc.. 

でそれを見る方法です。しかし、もし私が今、リポジトリを作成しようとしていたら、それはこのように見えますか？

​​

これは良い方法ですか？ 私はDDDが初めてであることは言うまでもありません。

Answer 1

私は、集約境界とエンティティを単なる階層以上のものとして見る必要があると思います。チャンスは、あなたはそれより豊かなモデルを持つでしょう。

集計が正しいかどうかを確認する最初の方法は、その中の各エンティティを確認し、「これに直接アクセスする必要がありますか」と尋ねることです。はいと答えた場合、そのエンティティはおそらく集合体の一部ではありません。

あなたのドメインについて詳しく知りませんが、私はStoreが本当に集約していると推測しています。一方、セールスはより複雑です。はい、販売は店舗で行われますが、販売を個別に使用する必要がありますか？ストアでの作業の範囲外にそれらを必要とする場合、Salesはおそらくその集合体の外にあります。

私は、スタイルと色の両方が不変で再現可能であると想像しているので、この場合は値オブジェクトになる可能性が高いです。ゾーンは店舗固有のものか、それとも変化しますか？

私は個人的に、紙面（またはホワイトボード）上のドメイン内のすべての項目を識別することに価値があります。私はステークホルダーとのディスカバリー段階を経て、そこに出て行きます。次に、これらの言葉を会話の指導者として使用して、それらがどのように関連しているかを理解しようとします。十分にステークホルダーにインタビューすると、彼/彼女が与える記述は実際にあなたが探しているもののほとんどを定義します。

死んだ馬を打ち負かすのではなく、エヴァンスの本は確かに読んだり読んだりする価値があります。少し乾燥していますが、非常に洞察力があります。クイックスタートアップのためには、基本的にEvansの書籍の要約であるInfoQのfree bookを読むことができます。

Answer 2

"Store"オブジェクトの背後にある "Zones"、 "Sales"などのすべての機能を非表示にしたくないため、Storeは集約ルートではないようです。そうすれば、 "Store"オブジェクトは非常に膨らんでしまうかもしれません。

"Store"、 "Zone"、 "Sale"は独自のリポジトリを持つことができます。

Answer 3

集約ルーツは、トランザクション、ディストリビューションおよび同時実行（Eric Evans via Gojko Adzic）の一貫性の境界です。

2人で同じストア内の異なるゾーンを変更すると、並行処理の競合が発生しますか？そうでなければ、おそらくゾーンは店舗とは別の独自の集計ルートでなければなりません。