0

問題

次の 4 つのエンティティがあります。

class Product : Entity<Product> {
    public virtual String Title { get; set; }
    public virtual Category Category { get; set; }
    public virtual Vendor Vendor { get; set; }
}

class Category : Entity<Category> { /* properties */ }
class Vendor : Entity<Vendor> { /* properties */ }

これら 4 つのいずれもコンポーネントIAggregateRootとして定義されておらず、どれを集約ルートとして使用する (インターフェイスでマークする) べきかわかりません。

新製品の作成中に、ベンダーのリスト、カテゴリに簡単にアクセスしてページに表示する必要があります。

Repository次に、これらのエンティティごとに 3 つのインスタンスがあるはずです。

脇

私はいくつかの大規模なプロジェクトを見てきました。彼らは、Vendor、State、TechnicalOptions などの独立したエンティティのリストを大量に使用しています。総根を持つものを設計することは論理的だと思いますが、DDD の原則がそこに適しているかどうかはわかりません。

4

2 に答える 2

7

それらは異なる集約のように見え、カスケード削除のルールを適用することで確認できます:

カスケード削除のルールは、集約にする必要があるエンティティまたは VO のグループがあるかどうかを判断するための良い方法として引用されることがあります。親が削除された場合、その集約の他のすべての部分も削除されます。したがって、削除される親がすべての子も削除することが意味をなさない場合、Aggregate はありません。古き良き参照があるだけです。

あなたの場合、製品が削除された場合、他の製品に関連している可能性があるため、関連するすべてのカテゴリをカスケード削除したくありません(このルールを他のエンティティに適用できます)。したがって、おそらくそれぞれに1つのリポジトリがあります

于 2013-08-05T08:16:43.467 に答える
0

1 つの AR が別のインスタンスを参照しないようにする必要があります。ID で参照するか、値オブジェクトを使用してください。

次に、ドメイン モデルに対してクエリを実行しないようにしてください。むしろ、必要なデータを返すために薄いクエリ レイヤーを作成します。パフォーマンスを向上させるために、クエリ レイヤーの一部のデータを非正規化することもできます。

于 2013-08-05T12:46:29.017 に答える