イベント駆動型アーキテクチャでのビジネスフローをどのように監視できるでしょうか。
Kafkaブローカーからのメッセージを発行および読み取るSpring Bootアプリを使用して、イベント駆動型アーキテクチャーをセットアップすることを計画しています。
それが通常のイベント（注文の発行、支払いの処理/失敗、アイテムの予約、在庫なしの在庫状況、注文の発送など）を伴うeコマースアプリケーションであるとしましょう。
私のビジネスコンテキストでは、これが発生するのではないかと心配しています。
問題は、プログラムのテキストで明示されていないため、そのようなフローを確認するのが難しい場合があることです。多くの場合、このフローを理解する唯一の方法は、稼働中のシステムを監視することです。これにより、そのようなフローのデバッグと変更が困難になる可能性があります。危険は、その大規模なフローを見失うことなく、将来のトラブルに備えるために、イベント通知を使用してうまく分離されたシステムを簡単に作成できることです。パターンはまだ非常に便利ですが、トラップに注意する必要があります。
Martin Fowlerの記事、イベント駆動とはどういう意味ですか から
問題は、このように分離され、イベントが豊富なアーキテクチャで発生するビジネスフローのグローバルなビューをどのように維持できるかです。
問題は、プログラムのテキストで明示されていないため、そのようなフローを確認するのが難しい場合があることです。多くの場合、このフローを理解する唯一の方法は、稼働中のシステムを監視することです。
これには2つの異なる側面があります。フローのロジックをどのように集中化するか、および監視時にフローをどのように識別するかです。
可能な解決策を監視するために、 相関および因果関係ID を使用します。すべてのイベントには、ランダムで一意のIDが付けられます。フローの相関IDは、元のイベントの一意のIDであり、そのフローの一部である連続する各イベントの個別のフィールドにコピーされます。因果関係IDは、現在のイベントに直接つながるフロー内の前のイベントの一意のIDであり、イベント間の因果関係を判別するのに役立ちます。この点で便利なのは、事実が必要になった後のログ集計だけなので、フローの簿記を行う必要がある中心的なコンポーネントがないことです。
フローのロジックを集中化するための解決策は、 sagas and process managers を使用することです。サガは、複数の部分と、場合によっては複数の境界コンテキストにまたがる、イベントが発生したシステムで長時間実行されるフローです。プロセスマネージャは、パーツを相互に接続するソフトウェアです。それ自体はビジネスロジックを実装していませんが、イベントをコマンドにマッピングしてシステムの他の部分にマッピングしているだけです。
ちなみに、イベントの発生したシステムには、フローの識別よりも多くの問題があります。有用なリソースは、Microsoftの CQRS Journey の本です。これは、実際のシステムを通じて、これらが何であり、どのように対処するかを示しています。
Context map を使用すると、境界付きコンテキストとその関係の概要を確認できます。
次に、Boundedコンテキスト内で、コードを利用して、システムがどのように機能するかを詳細に表示できます。ここには、コマンドを処理してイベントを発行する集約があります。次に、イベントに反応し、アグリゲートにコマンドを送信することにより、より高いレベルのビジネスプロセスを調整するSagas/Processマネージャーがいます。
次に、メッセージがシステムをどのように移動しているかをライブビューで確認できます。私は これのようなもの を過去にやったことがあります。