5

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

Postsを定義するクラスとCommentsを定義する別のクラスを持つことができるので、これは私には理にかなっています。この 2 つは非常に密接に関連しているため、これは集約の理想的な候補になります。しかし、UsersクラスとそのPostsとの関係をどのように表現すればよいでしょうか?

Posts/Comments集計でユーザーを集計すること、またはユーザーを単独で保持し、古き良き参照を介して関連付けを行うことは理にかなっていますか?

Google を使用して自分で答えを探してみましたが、見つけた多くの例は単なるスタンドアロンです。つまり、Posts/CommentまたはOrderOrderLineなどです。他の関連するクラスがどのように適合するかを示すものは見つかりません。

私はこれを特定の何かに適用しているわけではありませんが、PHP や Java/C# はおそらくこれらのアイデアを使用する領域になるでしょう。いずれにせよ、私は逃げ出してモンスターを作成する前に、これらのアイデアやコンセプトのいくつかを探求し、理解しようとしています. :)

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

4

1 に答える 1

5

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

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

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

Post が集約ルートであるため、ユーザーは独自の集約であり、すべての投稿への関係を含むことができます。このメソッドを PostRepository に実装して、特定のユーザーによるすべての投稿を取得することもできます。それが役立つことを願っています!

于 2009-08-05T19:01:00.167 に答える