イベントフローとイベントソーシング

イベント ストリーミングとイベント ソーシングは、イベント駆動型アーキテクチャにおける 2 つの関連する概念ですが、異なる概念です。

イベント ストリーミングは、システム内で発生するイベントを継続的にキャプチャして記録するプロセスです。これらのイベントは、すぐに処理して分析することも、後で分析するために保存することもできます。イベント ストリーミングは通常、金融取引やソーシャル メディア プラットフォームなど、大量のリアルタイム データを処理する必要があるシステムで使用されます。

次に、人気のある Kafka メッセージング システムを使用した Go でのイベント ストリーミングの簡単な例を示します。 リーリー

イベント ソーシングは、アプリケーション状態のすべての変更を一連のイベントとして保存するシステムを構築するためのパターンです。これらのイベントを使用して、任意の時点でのアプリケーションの状態を再構築できます。イベント ソーシングは、金融システムや医療システムなど、監査可能性、トレーサビリティ、コンプライアンスを必要とするシステムでよく使用されます。

以下は、Go でのイベント ソーシングにインメモリ イベント ストレージを使用する簡単な例です。

リーリー

イベント ソーシングは、集計への各変更をイベントとして記録し、それを連続ストリームに追加する方法です。アグリゲートの最終状態を再構築するには、これらのイベントを順番に読み取ってアグリゲートに適用する必要があります。これは、作成、読み取り、更新、削除 (CRUD) システムで実行されるオンザフライ変更とは対照的です。 CRUD システムでは、レコードの状態に対する変更はデータベースに保存され、基本的に同じ内容が上書きされます。

以前のバージョンの集計。

価格変更が Products テーブルに保存されると、価格のみが更新され、他の部分は変更されません。ただし、このアプローチでは、図 5.1 に示すように、以前の価格や変更の背景が失われる可能性があります。

新しい価格や主要なメタデータ (調整の理由など) を含む情報を保持するために、変更レコードはイベント テーブルにイベントとして保存されます。必要に応じて取得できるように、以前の価格は変更されません。

効果的なイベント ソーシングを実現するには、強力な一貫性が保証され、オプティミスティック同時実行制御を使用するイベント ストアを使用することをお勧めします。実際には、これは、複数の変更が同時に発生した場合、最初の変更のみをストリームに追加できることを意味します。後続の変更は再試行する必要があるか、失敗する可能性があります。

以上がイベントフローとイベントソーシングの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。