ドメインイベントとサービスバスを使用してCQRS＆DDDを使用する場合の視界の変化を示す

Question

ドメインイベントを使用して読み取りモデルを構築するシステム内のフローについて少し混乱しています。特に、ユーザーがコマンドを完了したときにデータ（およびそのビュー）が変更されることを期待するという事実にどのように対処しますか？ページはリロードされていますか？

イベントとサービスバスを使用して、CQRを使用してシステムの1つの設計をよりインラインで移動したいと考えています。

私の流れがそうなるとしましょう：

1. ユーザーはビューのボタンをクリックして、アカウントから支払い方法を削除するタスクを実行します。

2. コントローラーは、支払いmethodremovalserviceを呼び出し、それをcoscountid＆painemetodidに渡します。

3. コントローラーはAccountrePositoryを使用してアカウントを取得し、アカウントを呼び出します。RemovePaymentMethod（ID）

4. アカウントは、操作が発生する可能性があることを検証し、イベントPaymentMethodRemovedMessage（AccountID、PaymentMethodid）を公開する

5. イベントの公開は非同期であるため、サービスから戻り、コントローラーからのビューを返す必要があります - しかし、実際のデータはまだ更新されていません!

6. ハンドラー、iHandle <PayuneMethodRemovedMessage>は、イベントを聞き、DBから実際の行を削除します

それで、何をすべきか？

たとえば、支払い方法を表示しているDIVを削除することができました。これはAjaxシナリオで機能する可能性がありますが、JavaScript以外のクライアントをサポートするためにPost-Redirect-Getを使用している場合はどうでしょうか。それから、私は私のGETを発射し、潜在的に更新される前に、物事のクエリ側からデータを読み取ります。

支払い方法を削除するというリクエストが提出されたという通知を表示するだけですか？ （これは友好的ではないようであり、注文を送信するのに理にかなっていますが、アドレスを変更することではありません）。

非同期イベントとして変化の実装を調整し、現在の変更を反映するユーザーデータを表示する方法はありますか？

編集：私の質問は非常に似ています CQRS、DDD同期レポートデータベース 私は言わなければなりません、そこに与えられ、ここでも言及されている答えは、それに少し匂いがします - UIを争い、いわば読み取りDBでバンドから外れたアップデートを表示します。私は少しきれいな何かを望んでいました。

Answer 1

リクエスト/応答モデルにロックされている場合、相関したリクエスト/応答パターンを採用できます。詳細については、NSBダウンロードのAsyncページのサンプルをご覧ください。これは、ASP.NET設定でのリクエスト/応答を示しています。それがあなたのものであるならば、いくつかのASP.NET MVCの例があります。

非同期処理を導入すると、データが古くなることを受け入れています。 DBを照会した瞬間、データはすでに古いものであると主張することができます（ネットワークレイテンシ、レンダリング時間など）。データはすでに古いので、何歳で十分なのかと尋ねる必要があります。

もう1つ考慮すべきことは、処理が少し順調であるということです。ステップ3は、サーバーに送信する前にコマンドを検証する必要があり、その後、ステップ3、4は6の後に行われます。データベースは、コマンドが有効である場合にのみ更新する必要があり、データベースが正常に更新された場合にのみイベントを公開する必要があります。

Answer 2

この問題は「最終的な一貫性」と呼ばれます。それにアプローチする明確な方法があります。最初のポイントは、すべてのシステムが非同期イベントを使用しているかどうかにかかわらず、最終的な一貫性を持っていることです。他のほとんどのシステムがアップデートが完了するまでユーザーを待機させる一方で、それを明示的にすることを選択しただけです。どちらのアプローチも、明示的に選択されている限り有効です。

しばらく前に、私はあなたが役立つかもしれないこのテーマに関するブログ投稿を書きました。ここで見つけることができます： UIの最終的な一貫性を処理する4つの方法

これが短いバージョンです：

オプション1-確認画面を使用します。携帯電話で銀行アプリを使用している場合、おそらくこれを実際に見たことがあります。いくらかのお金を譲渡し、プロセスの最後に、アカウントに戻される前に確認画面に移動します。これにより、システムが最新の状態に戻る時間が与えられます。

オプション2-偽造します。ユーザーが試みている操作が成功する可能性が非常に高い場合、それを偽造することは正当なアプローチになる可能性があります。これは、需要の高いチケットを購入するときによく使用されます。トランザクションは通過する可能性がありますが、後で会社はチケットを発見しました。会社の利益は、両方の顧客を失う危険を冒すのではなく、販売をしていることです。システムが慎重に構築されている限り、この状況はめったに発生しないはずであり、したがって、全体的に問題ではありません。

相関IDを使用して、運用の成功または失敗を購読できるようにすることもできます。

とにかく、それが思考のためにいくらかの食べ物を提供することを願っています。