集計とリポジトリ集計の決定方法

Question

私は最近、クライアントコードが関係するカーペットの下での永続性のすべての詳細をブラッシングする方法として、リポジトリパターンを検討してきました。その周囲を読んでいる間に、リポジトリは、単純なクラスではなく、集計の責任を負っているようです。

投稿と別の定義コメントを定義することができるので、これは意味があります。この2つは非常に密接に関連しているため、これは集約の理想的な候補になります。しかし、私はどのようにのユーザクラスとその関係を表すでしょうか投稿？

それは、記事/コメント集計を持つユーザーを集約しても意味が、あるいはそれ自体でユーザーを維持し、単に古き良き参照を経由して関連性を持っていますか？

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

これは具体的なものには適用されませんが、PHPやJava/C＃はおそらく私がこれらのアイデアを使用して探す領域です。いずれにしても、私は逃げ出して怪物を作り出す前に、これらのアイデアやコンセプトのいくつかを試してみることにしています。 :)

ありがとうございます。

Answer 1

リポジトリパターンはかなり緩やかに定義されており、必ずしも集約パターンとの関係はありません。しかし、あなたが物事を行うDDDの方法に加入すれば、はい、リポジトリは集合体に固有です。

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

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

ユーザは、Postが集約ルートであるため、自分の集計であるすべての投稿との関係を含むことができます。 PostRepositoryでこのメソッドを実装して、特定のユーザーがすべての投稿を取得することもできます。希望が助けてくれる！