DDD-アグリゲートルートのリポジトリはアグリゲートの保存を処理しますか？

既存のアプリケーションのグリーンフィールドモジュールにDDDのようなアプローチを使用しています。アーキテクチャが原因で100％DDDではありませんが、いくつかのDDDの概念を使用しようとしています。：2つのエンティティからなる-私は（私はまだDDDについて学んだ私はそれが適切な用語だと思う）有界コンテキストを持っているConversationとMessage。メッセージは会話なしでは存在せず、システム内のすべてのメッセージは会話の一部であるため、会話がルートです。

私が持っているConversationRepository、データベース内の会話を見つける（それは本当に多くのゲートウェイのように、私は用語「リポジトリ」を使用しますが）クラスを。会話を見つけると、（ファクトリを介して）その会話のメッセージのリストも作成します（プロパティとして公開されます）。これはMessageRepository、会話が取得されたときにのみ存在するため、本格的なクラスは必要ないと思われるため、物事を処理する正しい方法のようです。

ただし、メッセージの保存に関しては、メッセージの集約ルートであるため、これはConversationRepositoryの責任ですか？つまり、ConversationRepositoryで、たとえばAddMessageMessageをパラメーターとして受け取り、データベースに保存するというメソッドが必要ですか？または、メッセージを検索/保存するための別のリポジトリを用意する必要がありますか？論理的なことは、エンティティごとに1つのリポジトリのようですが、「コンテキストごとに1つのリポジトリ」も聞いたことがあります。

DDDアプローチを最大限に活用したい場合は、ブルーブックを読む価値があります。DDDパターンは簡単ではありません。各パターンの本質を知ることは、どのパターンを使用するか、アプリケーションをレイヤーに分割する方法、集計を定義する方法などを検討するのに役立ちます。

言及している2つのエンティティのグループは、バウンドコンテキストではなく、おそらく集合体です。各アグリゲートには、他のすべてのオブジェクトのアグリゲートへの単一のエントリポイントとして機能するエンティティであるアグリゲートルートがあります。そのため、エンティティと、アグリゲートルートではない別のアグリゲート内の別のエンティティとの直接的な関係はありません。

リポジトリは、他のオブジェクトの走査では簡単に取得できないエンティティを取得するために必要です。通常、リポジトリには集約ルートが含まれますが、通常のエンティティのリポジトリも存在する可能性があります。

あなたの例では、会話は集合ルートのようです。会話はアプリケーションの出発点かもしれませんし、他のオブジェクトを簡単にたどることで満足にアクセスできないように、詳細な基準でそれらを照会したいかもしれません。このような場合、クライアントコードに、クエリ、追加、または直接削除する一連のメモリ内会話の錯覚を与えるリポジトリを作成できます。一方、メッセージはカンバセーションのトラバーサルによって簡単に取得できます。詳細な基準に従ってメッセージを取得するのではなく、カンバセーションのすべてのメッセージを一度に取得したい場合があるため、リポジトリは不要です。

ConversationRepositoryはメッセージの永続化において役割を果たしますが、あなたが言及したような直接的な役割は果たしません。したがって、ConversationRepository（そのメソッドはむしろConversation自体に属します）にはAddMessage（）はありませんが、代わりに、RepositoryがConversationを永続化するたびに、ORMフレームワークを使用する場合は透過的に、Messagesを永続化することをお勧めします（N）Hibernateなど、必要に応じてアドホックSQLを使用するなど。

あなたは作成できConversationServiceをし、注入IConversationRepositoryとIMessageRepositoryをそのコンストラクタで。単純なCRUD操作にはリポジトリを使用し、その他すべて（キャッシュ、ロジックの保存など）にはサービスを使用します