1

ドメイン内に 4 つのエンティティがあるとします。Productつまり、生産されるエンティティTechnology、製品タイプを定義するエンティティ、Material製造プロセス中に使用されるエンティティ、およびCategoryMaterial属するエンティティです。Categoriesカテゴリ内にネストできるものは多数あり、階層の深さに制限はありません。のProductさまざまな組み合わせで を作ることができますMaterials

Technology特定の parent を追加または削除して定義するとしましょうCategories。次に、サブツリーに属するものにProduct基づいて作成しTechnology、追加/削除します。MaterialsTechnology's Categories'

特定のに属するサブツリーのトップレベルCategoriesのリストをレンダリングしたい場合、効率的にするには、 の内部動作 (ネストされたツリーの実装など) を知る必要があります。そうしないと、一連のコレクションをロードすることになり、RDBMS のすべての利点が失われます。MaterialsCategoriesProductProductRepositoryCategoryRepository

ドメイン駆動設計に関して私の目標を達成する正しい方法は何ですか?

4

2 に答える 2

1

トップレベルのリストをレンダリングしたい場合...

「レンダリング」はプレゼンテーションの問題です。ドメイン モデルの設計に影響を与えるべきではありません。

したがって、そのような種類のビューを表示する必要がある場合は、作成できる最高の SQL クエリを使用してください。

私が理解できる限りProduct、リポジトリによって提供されるクラスには の識別子のみを含める必要がMaterialsあり、資料には関連するの識別子Categoriesのみを含める必要があります。ただし、これは、製品が不変条件を強制するカテゴリを必要とする場合にのみ当てはまります!

ただし、要件の説明から、私は DDD アプローチではなく、より単純な CRUD アプローチを採用します。経験則として、ビジネス ロジックを理解するためにドメイン エキスパートを雇う必要がない場合 (およびすべてのビジネス ルールを RDBMS 制約に再適用できる場合)、DDD は必要ありません。

于 2013-08-20T12:44:59.513 に答える