6

集約ルートの設計に問題があります。これが私の心の中での見方です:)

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..

これに基づいて、私の集計ルートはストアになります。しかし、その周りにリポジトリを作成するとしたら、次のようになりますか?

public class StoreRepository()
{
  Store GetById() {...}
  StoreZone GetZone() {...}
  List<StoreZoneStyle> GetStylesByZone() {...}
  List<Color> GetColorsByStyle() {...}
}

それは継続する良い方法ですか？言うまでもなく、私は DDD の初心者です。

4

3 に答える 3

7

集合体の境界とエンティティを単なる階層以上のものとして見る必要があると思います。おそらく、それよりもリッチなモデルが得られるでしょう。

集約が正しいかどうかを判断する最初の方法は、その中の各エンティティを見て、「これは直接アクセスする必要がありますか?」と尋ねることです。はいと答えた場合、そのエンティティは集計の一部ではない可能性があります。

あなたのドメインについて詳しく知らなくても、Store は確かに集合体であると思うかもしれません。一方、販売はより複雑です。はい、販売は店舗で行われますが、独自に販売を利用する必要はありますか? 店舗での作業の範囲外でそれらが必要な場合、Sales はおそらくその集計範囲外です。

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

個人的には、ドメイン内のすべてのアイテムを紙 (またはホワイトボード) で特定することに価値があると考えています。私は利害関係者と一緒に発見段階を経て、彼らをそこに連れて行きます. 次に、これらの単語を会話のリーダーとして使用し、それらがどのように関連しているかを理解しようとします。利害関係者に十分にインタビューすれば、その利害関係者が提供する説明によって、探しているもののほとんどが実際に定義されます。

死んだ馬を打ち負かすわけではありませんが、エヴァンスの本は間違いなく手に入れる/読む価値があります. 少し乾いていますが、非常に洞察力があります。簡単なジャンプスタートとして、基本的に Evans の本の要約である InfoQの無料の本を読むことができます。

于 2009-10-28T20:22:15.413 に答える
5

Aggregate Roots は、トランザクション、ディストリビューション、および並行性の一貫性の境界です ( Eric Evans via Gojko Adzic )。

2 人のユーザーが同じストア内の異なるゾーンを変更すると、同時実行の競合が発生しますか? そうでない場合、おそらくゾーンは、ストアとは別の独自の集約ルートにする必要があります。

于 2011-02-12T04:14:30.760 に答える
2

「Store」オブジェクトの背後にある「Zones」、「Sales」などのすべての機能を非表示にしたくないため、「Store」は集約ルートではないようです。そうすれば、「ストア」オブジェクトが非常に肥大化する可能性があります。

「ストア」、「ゾーン」、および「セール」は、独自のリポジトリを持つことができます。

于 2009-10-28T20:17:50.773 に答える