3

佐賀が作成される前に公開されたイベントに基づいて意思決定が行われる場合、佐賀をどのように処理するかについて質問があります。

これが私の問題を説明するための例です：

CustomerARとOrderARがあると想像してください。customerARが作成されると、検証プロセスが開始され、そのプロセスの結果は、顧客が特別な許可なしに自由に使用できる注文の金額になります。このプロセスは文脈から外れているため、ここでは詳しく説明しません。金額が計算されると、コマンドが計算された金額でCustomerARに送信され、CustomerARはその値でイベント（CustomerMaxOrderAmountEvent）を公開します。ここまでは順調ですね。

それから数週間後、顧客は注文をします。OrderARが作成され、OrderSagaが起動します。sagaは、注文が完全に作成されるまで待機してから、その注文に対してAutorizationCommandを送信する必要があるかどうかを判断する必要があります。その決定を行うには、CustomerMaxOrderAmountEventが公開されているかどうかと金額の値を知る必要があります。通常、OrderSagaはCustomerMaxOrderAmountEventもサブスクライブしますが、問題は、過去にすでに発生していたため、このイベントが発生しないことです。

これにどう対処すればいいですか。読み取りモデルにクエリを実行して値を確認する必要があります。コマンドを送信して値を取得する必要があります。CustomerARを参照する必要があります。また、佐賀のすべての履歴イベントを再生して、彼がすでに履歴を認識している必要があります。

アップデート

これは、この具体的な例ではなく、概念に関するものであることに注意してください。この例は、問題を明確にするためのものです。「同じ境界コンテキストの一部ではない、関連のない2つの集約ルート」。

助けてくれてありがとう。

メルビン

4

2 に答える 2

1

もっと簡単な解決策を探します。この情報を（たとえば、の形式でHasCustomerReachedMaxOrderAmount）佐賀を開始するイベントに追加するだけです。

2番目に選択するオプションは、Sagasで使用するように設計された読み取りモデルを準備し、そこからデータを照会することですが、Sagaが開始される前でも、必要なすべての情報を収集します。このエンリッチメントは、ARによって発生した元のイベントへのハンドラーによって実行できます。これは、Aggregate /BoundedContextの一部ではないためです。

ただし、ほとんどの場合、Sagasにはプロセスの形式でのみビジネスロジックを含める必要があるため、イベントで渡されるデータに基づくだけで十分です。これは非常に多くの場合、（例に従って）複数の佐賀になってしまう可能性があることを意味しOrderSagaますOrderWithMaxAmountSaga。

とはいえ、あなたが提供したサンプルシナリオを考えると、注文に承認が必要かどうかの決定は、むしろドメイン自体の一部であり、サガを開始するときに渡されるべきだと思います。

このシナリオを次のようにモデル化します-CustomerAR最大量を計算します。顧客が注文する->この顧客の最大金額に関する情報を使用しOrderARて作成され、追加の承認が必要かどうかを確認します->開始します。重要なのは、最大量に関する情報は、（変更できる場合）と（不変である場合）の両方にとって重要であるということです。OrderSagaCustomerAROrderAR

于 2011-09-08T12:12:22.127 に答える
0

私はDDDに手を出し始めたばかりで、kstaurchが言ったことを繰り返すつもりはありませんが、ここにあなたのシナリオを見ていたいくつかの考えがあります。

  1. 最大注文額を請求情報の一部にするのはどうですか？それはどこかで取得する必要があり、支払い処理が拒否される状態に注意してください。

  2. 佐賀が常に認証コマンドを送信するが、最大注文画面を処理するのは認証部分である場合はどうなりますか？「金額がXドルを超えている場合は承認を取得する」と言っている場合、ビジネスモデルも「Xドルを下回っている場合は自動承認」と見なしている可能性があります。利点は、すべての承認の考慮事項（承認を取得するかどうかを含む）を承認エンティティまたはサガに移動できることです。

于 2011-09-19T14:06:17.690 に答える