集約とリポジトリ。集計を決定する方法は？

Question

最近、クライアントコードが関係するカーペットの下で永続性のすべての詳細をブラッシングする方法としてリポジトリパターンを検討しています。読んでいると、リポジトリは単純なクラスではなく、[通常？]集約を担当しているようです。

これは、投稿を定義するクラスと、コメントを定義する別のクラスを持つことができるので、私にとって理にかなっています。 2つは非常に密接に関連しているため、これは集計の理想的な候補になります。ただし、 Users クラスと、その Posts との関係をどのように表現しますか？

ユーザーを Posts / Comments 集計で集計するのは理にかなっていますか、それとも Users を単独で保持し、古き良き時代の参照を介して関連付けを行うだけですか？

Googleを使用して自分で答えを探してみましたが、見つかった例の多くはスタンドアロンです。つまり、投稿/コメントまたは注文と注文ラインなどです。他の関連クラスがどのように適合するかを示すものは見つかりません。

私はこれを特定のものに適用していませんが、おそらくこれらのアイデアを使用したいと考えているのはPHPまたはJava / C＃です。いずれにせよ、逃げ出してモンスターを作成する前に、これらのアイデアや概念のいくつかを探求して頭を動かそうとしています。 ：）

お時間をいただきありがとうございます。

Answer 1

リポジトリパターンはかなり大まかに定義されており、必ずしも集約パターンとは関係がありません。ただし、DDDの方法をサブスクライブする場合、はい、リポジトリは集約に固有です。

では、DDDの観点からこれを見てみましょう。 DDDは、アグリゲート内のオブジェクトは別のアグリゲートルートへの参照を持つことができますが、アグリゲート内のオブジェクトにはルートを介してのみアクセスできると言います。集約を決定するための経験則は、ルートを削除するときに削除する必要があるものです。ただし、DDDは、関係がドメインに存在するからといって、ドメインのモデルに存在する必要がないため、ほとんどの方法論よりも関係の使用を推奨していません。

あなたの場合、投稿を削除するとき、コメントも削除すると思いますが、投稿を作成したユーザーやコメントしたユーザーは削除しないと思います。したがって、投稿/コメントの集計を定義することは正しいですが、ユーザーをその集計にグループ化することは意味がありません。

ユーザーは独自の集計であるため、Postは集計ルートであるため、すべての投稿との関係を含めることができます。このメソッドをPostRepositoryに実装して、特定のユーザーによるすべての投稿を取得することもできます。役に立てば幸いです！