現在も DDD について読んで学んでおり、現在取り組んでいるプロジェクトに適用しようとしています。私はまだ Aggregates に頭を悩ませようとしていて、興味深い質問に出くわしました。
2 つの集合体があり、1 つにはルート用のアカウント エンティティがあり、もう 1 つにはルート用のユーザー エンティティがあるとします。
アカウントはユーザーなしでは作成できませんが、ユーザーは作成できます。そのため、両方が独自の集計のルートとして機能します。Aggregates には他のエンティティが含まれますが、それは私の質問にとって重要ではないことに注意してください。
いくつかのビジネス ルール: 1) アカウントが作成されたら、それをユーザーに関連付ける必要があります。ユーザーが存在しない場合は、最初に作成する必要があります。
2) アカウントが削除された場合、関連するユーザーも削除する必要があります。
3) ユーザーの作成時に、アカウントに関連付ける必要はありません。
3) ユーザーが削除されるとき、それがアカウントに関連付けられている場合は、それも削除する必要があります。
Account と User は独自の集合体を形成するため、おそらく独自のリポジトリが存在します。つまり、標準の Add、Delete、Find、および Delete メソッドは、これらのリポジトリごとに定義されます。
これらのシナリオを考えると、次のことを達成するための最良の方法は何ですか: 1) アカウントが作成されたら、そのユーザーのプロパティでメソッドを呼び出して、ユーザーが存在することを確認することを考えました。これは正しいですか？
2) アカウントが削除された場合、関連するユーザーも削除するにはどうすればよいですか。アカウントリポジトリから？しかし、それはユーザー リポジトリでコードを複製するだけではないでしょうか? それとも、リポジトリは相互に参照して呼び出すことができますか?
3) ユーザーが削除された場合、それがアカウントに関連付けられているかどうかを判断し、コードを複製せずに削除するための最良の方法は何ですか (おそらく 2 番目の質問に似ています)。
ロジックが 2 つのエンティティまたは集計にまたがる場合は、サービスの使用を検討することをどこかで読みました。しかし、クライアント (API が進化し、ユーザーが将来的に他のプレゼンテーションを使用すると仮定すると) がサービスをバイパスして単にリポジトリを呼び出すのを止めているので、私はそれに満足していませんか?
更新 1:
これはおそらく関連する質問であることに気付きました:集約ルート間の関係と制約をどのように強制する必要がありますか?