リポジトリーを設計するときに集約ルートを使用する必要がありますか？

多くのスレーブエンティティで構成されるマスターと呼ばれるエンティティがあります。

データベースに存在できるマスターは1つだけであり、リポジトリーを照会して、指定されたIDのスレーブを取得します。

最初にSlaveRepositoryを作成し、それをIDでクエリしました。それは問題なく機能し、他の開発者が私のリポジトリを使用できます。

次に、集約ルートについて考え、MasterRepositoryを作成してマスターを返し、それに対してループを実行して、必要なスレーブエンティティを取得しました。私がここで感じた問題は、これを他の開発者に公開すると、同じようにする必要があるため、GetSlaveByID（string id）と呼ばれるMasterRepositoryのメソッドを使用して、スレーブを直接取得できます（ループ機能を非表示にします） ）。

さて、私のリポジトリはMasterRepositoryと呼ばれていてもスレーブを返す必要がありますか？そしてもっと重要なのは、どちらが正しい道なのか？

私はDDDとTDDを適用しようとする初期段階にあるので、どちらが正しい方法であるかを判断する前に、おそらく多くのことを検討する必要があります。

ドメイン駆動設計のエリック・エバンスの方法によると、非集合ルートのリポジトリーは避けるべきです。

彼は明確に述べています：

データベースクエリで直接取得できるのは、集合ルートのみです。それ以外はすべて、トラバーサルを介して行う必要があります。

しかし、これは、ルートのリポジトリがすべての要件を満たす必要があることも意味します。アグリゲートの一部に直接アクセスする必要がある場合は、アグリゲートのルートオブジェクトまたはそのリポジトリがそのための役割を果たします。

したがって、集約ルートリポジトリに次のようなメソッドを含めることはまったく問題ありません。

Slave GetSlave(string id)

ただし、DDDの子のIDは実際のルートオブジェクトのコンテキストでのみ意味があり、ルートなしでは浅いため、この署名は少し危険です。

これにより、リポジトリでの実装のためのより良い、よりDDDのようなアプローチにつながります。

Slave GetSlaveOfMaster(Master master, string slaveId)
// or
Slave GetSlaveOfMaster(Identity masterId, Identity slaveId)

しかし、私はおそらくこのメソッドをリポジトリに置くのではなく、マスターエンティティ自体にスレーブをすばやくアクセスさせることでしょう。ハッシュテーブルとして公開されている可能性もあります。それは私が考えることができる最もクリーンなアプローチです。

//within the Master entity
Slave GetSlave(Identity slaveId);

これで話は終わりではありません。マスターの知識がなくてもスレーブをフェッチする必要がある場合は、集約とオブジェクトモデルについて考える必要があります。おそらく、スレーブがルートである2番目のアグリゲートが必要で、それらのカスタムリポジトリが必要です。その場合、スレーブはマスターの子であるだけでなく、おそらくマスターへの参照も保持する別個の階層になります。マスターなしでスレーブオブジェクトが存在できるかどうかを知ることは重要です。可能であれば、別の集計がおそらく進むべき道です。

一般に、集約境界内には1つのリポジトリのみが存在する必要があります。そして-Falconが言ったように-マスターとスレーブという2つの別々の集合体になるかもしれません。

ただし、質問の主な焦点はデータ検索であるように見えますが、DDDではそれが動作であるはずです。集合体の境界は、動作によって強制される制約（一緒に変化するものと適用される不変条件）の結果であり、集合体の内部構造はその選択の結果です。

たとえば、変更の必要性に応じて適切にグループ化した場合、外部リポジトリを呼び出す必要はそれほどありません。ほとんどの場合、Aggregateのビジネスオペレーションに必要なデータはすでに集計の境界内にあるはずです。異なる集計にアクセスする必要性は、おそらく一貫性のない境界のにおいです。