ドメイン駆動型設計の原則に適用するベストプラクティス？

Question

ドメインドリブンデザインは、時には本当に混乱することがあります。私はこの技術にはまだ新しいので、現在私を悩ませているシナリオに関するいくつかの回答をしたいと思います。

DDDの原則を使用して私の質問を表す簡単な図です。私の質問は、集約ルーツ、ドメイン検証、「行う方法」やベストプラクティスです。

1. このシナリオでは、ユーザーが書き込んだコメントの数をカウントする方法をどのように実装しますか？それは "レビュー"の方法でしょうか？または、リポジトリ（ReviewRepository）のメソッドにするのが最善でしょうか？
2. 他のエンティティに必要に応じてコメントにアクセスさせるにはどうすればよいですか？このシナリオを持つことは、「コメント」が「レビュー」集計の一部になっていないことを意味しますか？
3. コメントに他のエンティティとの構成関係がある場合はどうなりますか？そのエンティティへのアクセスをどのように管理しますか？コメントはこのエンティティまたはルートに責任がありますか？
4. このモデルに関する他の提案や事実はありますか？モデルを設計する際に私が仲間にするべきベストプラクティス？

ありがとうございます。

注：答えなければならない仲間DDD原則

ありレビューエンティティに少しの誤差。 Addメソッドの "Compte"は "Account"で、Cの代わりにAでなければなりません。

Answer 1

このシナリオでは、ユーザーが書き込んだコメントの数をカウントする方法をどのように実装しますか？

責任がレビューに属します。それは、コメントの集まりです。 Countは、任意の集計のファーストクラスの機能です。

他のエンティティにコメントをアクセスさせるにはどうすればよいですか？

コメントはレビューからアクセスできます。レビューは、コメントの集合です。

コメントに他のエンティティとの関係がある場合はどうなりますか？

具体的かつ具体的な例がなくても「何か」という質問に答えるのは難しいです。結局のところ、デザインはランダムな考えではなく、問題のドメインによって推進されます。

「その他」のエンティティの一部もコメントの構成に見える場合は、ドメインの専門家に戻って、本当のの責任がある場所を特定する必要があります。

質問は「レビューが削除された場合、コメントにどうなりますか？」という質問が1つあります。 「不思議な「他人」が取り除かれた場合、そのコメントはどうなるのか？」これは、責任を見つけるのに役立ちます。