CQRS +イベントのロールバックの取り扱いMicroservices

Question

我々はnodejsのcqrsドメインを使用してmicroservices、cqrs、イベント・ストアを使用している、すべてが魔法のように動作し、典型的な流れは次のようになり：

1. REST-> 2。サービス - > 3。コマンドの検証 - > 4。コマンド - > 5。集合体 - > 6。イベント - > 7。イベントストア（トランザクションデータ） - > 8。集約ID - > 9.で集計を返します。マイクロサービスローカルDBに格納します（本質的に読み取りDB） - > 10.キューへのイベントの公開

上記のフローの問題は、トランザクションデータの保存イベント・ストアへの格納とマイクロ・サービスへの記憶域の読み込みは、ステップ9で何らかの障害が発生した場合、別のトランザクション・コンテキストで発生します。すでにイベント・ストアに伝播されたイベントおよびすでに更新されている

ご意見をいただければ幸いです。

Answer 1

イベント・ストア内で、読取り側のレプリケーションが成功したかどうかを追跡できます。 ステップ9が成功するとすぐに、イベントを「複製済み」としてフラグを立てることができます。

このようにして、レプリケートされていないイベントを監視するコンポーネントを導入し、ステップ9をトリガすることができます。レプリケーションが複数回失敗したかどうかを追跡することもできます。

読み取り側（手順9）を更新し、複製されたものとしてイベントを表示すると、一貫して発生するはずです。あなたはここでサガパターンを使うことができます。

Answer 2

上記フローの問題は、トランザクションデータがmicroserviceの読み出されたデータにイベント・ストアおよびストレージにすなわち永続性を保存するので、私はどのように処理するかステップ9で何らかの障害が発生した場合は、別のトランザクションコンテキストで起こるということですすでにイベント・ストアに伝播されたイベントおよびすでに更新されているアグリゲート

後で再試行します。

「予約記録」はイベントストアです。ダウンストリームビュー（「公開イベント」、読まれたモデル）は、記録の帳から得られます。彼らは通常、時間の記録の本の背後にある（eventual consistency）、通常はお互いに同期されていません。

あなたが持っているかもしれないので、時間のある時点で、105件のイベントが記録の本に書かれていますが、唯一の100は、キューに公開し、あなたのサービスデータベースでの表現のみ98

の更新から構築通常、ビューは2つの方法のいずれかで行われます。もちろん、新しい表現から始めて、各更新の一部としてすべてのイベントを再生することができます。また、イベント履歴のどの程度までビューのメタデータを追跡して、その情報を使用して次回のイベント履歴の読み込みを開始するかを決定します。

Answer 3

私は今、それをよりよく理解していると思います。 集計はまだ作成されていますが、集計が構築される前にあらゆるタイプの整合性の検証が行われる必要があります。読み取りサイドDBの更新中にエラーが発生した場合は、取り扱う必要があるマイクロサービスの 理想的なケースでは、集約が作成されますが、関連付けられたイベントは、すべての読取り依存関係が更新されないかぎり、未ディスパッチのまま残ります。 イベントストアにはまだすべてのイベントがあり、このようにして最終的な整合性が維持されます。