repository - ドメイン駆動設計-リポジトリと集約ルート

Question

フォーラムを含むドメインモデルがあります。

フォーラム、スレッド、投稿のエンティティがあります。

フォーラムはスタンドアロンのエンティティです。つまり、アグリゲートの一部としてスレッドが含まれていません。これは、スレッドが特定のフォーラムによって所有されていないためです（スレッドを別のフォーラムに移動できます）。

スレッドアグリゲートの一部として投稿をモデル化する必要があるかどうかはわかりません。投稿はスレッドなしでは存在できません。スレッドを削除すると、投稿をスレッドの一部にするように指示された投稿を削除する必要があります。

唯一のことは、投稿を編集するときにスタンドアロンで取得することもできるということです。つまり、IDで投稿を編集する場合です。

したがって、スレッドをフェッチしてから、スレッドエンティティのメソッドを介して適切な投稿をフェッチするよりも、投稿リポジトリを用意する方がこの目的に適していると思います。

個別の投稿リポジトリを持つことの唯一のことは、投稿を追加するとき、つまりaddPost（Post）の場合、スレッドIDが投稿エンティティに割り当てられていることを確認する必要があるということです。集計を使用すると、スレッドエンティティにaddPostメソッドがあると思います。

制限されたコンテキストについて考える必要がありますか？投稿エンティティとリポジトリを作成し、投稿エンティティも含むスレッド集計を作成できますか？

スレッド/ポストアグリゲートを使用しなかった場合、スレッドを削除するときにポスト削除をどのように処理しますか？スレッドリポジトリでdeleteThread（Thread）を呼び出し、ポストリポジトリでdeletePostsByThreadId（id）を呼び出すサービスを作成する必要がありますか？

ここでのDDDの方法は何ですか？

Answer 1

あなたの場合、DDDが良い考えかどうか疑問に思っています。つまり、フォーラムは本質的にデータ指向です。おそらく、最も単純なアプローチを検討し、従来のデータ指向テクノロジを使用してデータをクエリする必要があります。(つまり、LINQ、Hibernate、プレーン SQL、エンティティ フレームワーク、またはプラットフォームに応じて必要なもの)

あなたのプログラムはドメイン層を必要としないかもしれません。さもなければ、データを保持するクラス ForumDTO と、ビジネスロジックを保持するフォーラム、投稿またはスレッドと同じものになるでしょう。私にはアンチパターンのようです。

どう思いますか ？

アップデート

Eric Evans の本を読むことをお勧めします。この本には、DDD が非常によく適合する複雑なドメインの優れた例が掲載されています。この本を読んだ後、私は学んだことを適用することに非常に熱心でしたが、場合によってはデータ指向のアプローチがより適切であることがわかりました。

私にとって、フォーラムには複雑なドメイン ロジックがほとんどないため、データ レイヤーとドメイン レイヤーの間に 1<->1 マッピングが発生することになります。これは、前述のように、重複とオーバーヘッドを意味します。

ドメインの説明を見ると、あなたのアプローチはデータ指向のようです。たとえば、直感的にフォーラムにはスレッドがあり、スレッドには投稿がありますが、説明したドメインはそれを反映しておらず、データベーススキーマに合わせてオブジェクトモデルを正規化しているようです(正規化されます)。

フォーラムは、集約のルートになるのに最適なクラスのようです (より直感的です)。

本当に DDD アプローチを使用したい場合は、エンティティにリポジトリを挿入し、要件に応じて、ドメイン オブジェクトに意味のある名前を thread.GetLastPostOf(User user) として付けることができます。

しかし、メソッド GetPostById を備えたリポジトリが必要だというあなたの意見には同意します。