私が理解しているように、境界付きコンテキストにはモジュールを含めることができ、モジュールには多くの集約ルートを含めることができ、集約ルートにはエンティティを含めることができます。永続性のために、各集約ルートにはリポジトリが必要です。
大規模なプロジェクトに多数の集約ルートがある場合、1 つは準備専用でもう 1 つは更新用のGeneric Repositoryを使用しても問題ありませんか? または、集約ルートごとに個別のリポジトリを用意して、より適切に制御できるようにする必要があります。
私が理解しているように、境界付きコンテキストにはモジュールを含めることができ、モジュールには多くの集約ルートを含めることができ、集約ルートにはエンティティを含めることができます。永続性のために、各集約ルートにはリポジトリが必要です。
大規模なプロジェクトに多数の集約ルートがある場合、1 つは準備専用でもう 1 つは更新用のGeneric Repositoryを使用しても問題ありませんか? または、集約ルートごとに個別のリポジトリを用意して、より適切に制御できるようにする必要があります。
GetById()
大規模で複雑なプロジェクトでは、一般的なリポジトリを使用することはお勧めしません。基本的な, GetAll()
... 操作を超えた特定のケースが多くある可能性が高いためです。
Greg Young は、汎用リポジトリに関する優れた記事を書いています: http://codebetter.com/gregyoung/2009/01/16/ddd-the-generic-repository/
1 つは準備完了用、もう 1 つは更新用の Generic Repository を使用しても問題ありませんか?
通常、リポジトリはエンティティの更新の保存を処理しません。つまり、リポジトリにはUpdate(EntityType entity)
メソッドがありません。これは通常、ORM の変更トラッカー/作業単位の実装によって処理されます。ただし、読み取りと書き込みを分離するアーキテクチャを探している場合は、間違いなくCQRSを確認する必要があります。
Web 上で公開されているサンプル DDD アプリケーションのいくつかで、各集約ルート リポジトリが継承するベース リポジトリ インターフェースを持っているのを見てきました。私は、個人的には、少し違うことをしています。リポジトリはアプリケーション コードのコレクションのように見えるはずなので、ベース リポジトリ インターフェイスは IEnumerable から継承するので、次のようになります。
public interface IRepository<T> : IEnumerable<T> where T : IAggregateRoot
{
}
そこにいくつかの基本メソッドを入れましたが、コレクションの読み取りを許可するものだけです。これは、集計ルート オブジェクトの一部がカプセル化されており、メソッド呼び出しによってのみ変更できるようになっているためです。
あなたの質問に答えるには、はい、一般的なリポジトリを使用しても問題ありませんが、すべてのリポジトリに継承されるべきではない機能を定義しないようにしてください。また、1 つのリポジトリで必要のないものを誤って定義してしまった場合は、それを必要とするすべてのリポジトリ インターフェイスにリファクタリングしてください。
編集: リポジトリを他の ICollection オブジェクトと同じように動作させる方法の例を追加しました。
CRUD 操作が必要なリポジトリでは、これを追加します。
void Add(T item); //Add
void Remove(T item); //Remove
T this[int index] { set; } //or T this[object id] { set; } //Update
純粋な DDD は、暗黙的に明示的にすることです。つまり、List() を使用せず、むしろ ListTheCustomerThatHaveNotBeSeenForALongTime() を使用します。
ここで問題となるのは、技術的な実装です。私の知る限り、ドメイン駆動設計は技術的な選択肢を提供しません。
汎用リポジトリが適しています。ただし、この汎用リポジトリの使用は ddd の精神に合わない可能性があります。ドメインによって異なります。
コメントありがとうございます。私が採用したアプローチは、ベース リポジトリ インターフェイスを ReadOnly と Updateable に分離することでした。すべての集約ルート エンティティには独自のリポジトリがあり、更新可能または読み取り専用のリポジトリから派生します。集約ルート レベルのリポジトリには、独自の追加メソッドがあります。汎用リポジトリを使用する予定はありません。
IReadOnlyRepository を選択したのには理由があります。将来的には、アプリのクエリ部分を CQRS に変換します。したがって、ReadOnly インターフェースのスーパータイプへの分離は、その時点で役立ちます。