次のシナリオがあります。
ショップになって所有者アカウントを取得するには、事前にリクエストを作成する必要があります。
ある日、リクエストを登録します。マネージャーがリクエストを確認して承認してから 2 日後、システムがショップとオーナーのアカウントを作成する必要があることを意味します。
私のモデルでは、リクエスト、ショップ、オーナー アカウントが 3 つの集計ルートであると考えていましたが、1 つのトランザクションで複数の集計を更新できないことを読みました。外部認証サービス) を別々の db サーバーに配置します。
問題は..まだリクエストがあり、承認されたら、2 つの集約ルート、ショップを作成する必要があります (すべてのショップ属性を使用して、連絡先の電子メールや電話の制限など、データにいくつかの不変条件しかありません)。 ) と所有者アカウント。
次に、1 つの所有者アカウントが他の誰かのショップを編集できるようにします (コラボレーターなど)。
どうすればそれをモデル化できますか?
ありがとう！
あなたの要件から、私のデザインは次のようになります。
2 つの境界付けられたコンテキスト:
ショッピング: 2 つの集計 ( Request と Shop ) があります。
認証: 1 つの集計 ( OwnerAcount )。
結果整合性が存在します。
(1) リクエスト集約には「承認」メソッドがあります。このメソッドは RequestAproved イベントを作成します。
(2) ショッピング BC は RequestAproved イベントを発行します。
(3) 認証 BC は、このイベントのサブスクライバーです。これは、OwnerAcount 集計を作成するイベントに反応します。
(4) OwnerAcount 集計のコンストラクター メソッドは、OwnerAcountCreated イベントを作成します。
(5) Auth BC は OwnerAcountCreated イベントを発行します。
(6) ショッピング BC は、本イベントのサブスクライバーです。Shop 集計を作成するイベントに反応します。
Shop集計を作成するトランザクションは、Request集計を作成したトランザクションとは異なります。
これが図です：
(注: イベントの種類ごとにメッセージ キューがあります。別のオプションとして、すべてのイベントの種類に対して 1 つのキューのみを使用することもできます)
