私はかなり長い間、そこにある他の投稿を集約ルートに相対的に見てきました。集約ルートを正しい方法で定義する方法がまったくわからないようです。集約ルートが集約ルートではない、またはその逆などの回答を見ました。私は少し混乱しています。問題は、私が頭の中にリレーショナル モデルを持っていることですが、DDD がそのように進まないことはわかっています。
関係モデルから集約ルートを定義する方法はありますか?
たとえば、それぞれがタスク、問題、およびメモを保持するジャーナル エントリを保持するジャーナルがあるとします。
集約ルートをどのように定義しますか? ルートはジャーナルですか? ただし、メモ、問題、およびタスクにアクセスする場合は、問題が発生する可能性があります。それらは、ジャーナルエントリへの参照を保持する集約ルートでもありますか?
わかりにくいので、もう少し詳しく教えていただきたいです。
ありがとう。
総根の概念は、理解するまで混乱を招く可能性があることに同意します。他のほとんどの概念と同様に、数回実行して練習すると簡単になります。
集約のポイントは、 1 つまたは複数のユース ケースのコンテキストで、一部の外部オブジェクトのオブジェクト トラバーサルを簡素化することです。ビジネス要件を満たすには、どこかから始めなければなりません。また、Journal が主に必要であることがわかった場合は、実際には集計ルートにする必要があります。自明ではないほとんどのドメインでは、複数の集約ルートがあると便利です。ユースケースの開始オブジェクトについて超自然的なことは何もありません。どこかから始める必要があります。
繰り返しになりますが、ポイントはオブジェクトのトラバーサルを単純化することであり、これによりシステムが単純化されます。したがって、Journal が実際に有用な出発点である場合は、Journal へのすべての呼び出しを最初に行ってください。特定のユースケースで、タスク、お金、時間、またはその他の有用なものが必要になった場合、呼び出し元のプログラムは、Journal のみに問い合わせることでそれらのものを取得します。このユースケースでは、他のオブジェクトは Journal 集約ルートの一部です。
他のユース ケースでは、Task を開始点とする方がより自然であり、したがって有用な場合があります。そのため、Task 集約ルートもある場合があり、これはユース ケースの Journal 集約ルートと重複する可能性があります。ただし、要求を満たすためにタスクとタスクのみを要求します（呼び出し元のプログラムが知る必要がある唯一の参照になります）
もちろん、リレーショナルデータベースはリレーショナルのままにすることができます。しかし、オブジェクト モデルを進化させて、集約 (開始点オブジェクト) の観点から要求を見るようにすると、データベースからの要求がより単純になります。
ユースケースを 1 つ (または 2 つ) レイアウトし、それを実行してみてください。必要に応じて、ユース ケースのコンテキスト内で質問してください。
HTH、
ベリル