7

イベントによって統合された複数のシステムがあり、それらすべてがイベント ソーシングを使用しているとします。イベントはどこに保存しますか?

私の場合、3 つのシステムがあります。

  • ショップであるウェブサイト
  • 顧客、製品などを管理する Web サイトのバックエンド。
  • 会計システム

これらのシステムの 1 つでドメイン イベントが発生するたびに、イベントが公開され、他のシステムで処理できます。すべてのシステムがイベント ソーシングを使用しています。

イベントをどこに保存するのか疑問に思っています。もちろん、各システムは処理したすべてのイベントを保存する必要があります。これは、イベント ソーシングを使用しているため、一度処理したイベントに依存するためです。

しかし、必要がないためにシステムがサブスクライブしなかったその他のイベントについてはどうでしょうか。システムが持続しなかった過去のイベントを処理する必要があるなど、要件が変更される可能性があるという事実に苦労しています。発生時にサブスクライブしなかったイベントをシステムが処理する必要がある場合、これらのイベントをどこから取得しますか?

この時点で、イベント ソーシングを使用しないシステムとは大きな違いがあると思います。データに依存するシステム A に機能を実装する必要があり、それは A では利用できないが、別のシステム B では利用でき、NHibernate のような ORM ツールを介して現在の状態を永続化する場合、そのデータを A から B にインポートするだけです。 . イベント ソーシングを使用するシステムは、現在の状態に到達するためにイベントに依存するため、過去に見逃したが現在必要なすべてのイベントをインポートする必要があります。

私にとって、この問題にはいくつかの異なるアプローチがあります。

  1. 各システムは、発行されたすべてのイベントを保存します。これにより、必要に応じてイベントを再公開したり、別のシステムにインポートしたりできます。
  2. 各システムは、(まだ) 処理する必要のないものも含め、発生したすべてのイベントを保存します。
  3. すべてのシステムからのすべてのイベントは、中央のイベント ログに保存されます。過去に発生したイベントを処理する必要があるが、サブスクライブしていない場合は、ここからインポートできます。

このような状況にどのように対処しますか？イベントをどこに保存しますか?

編集

Roy Dictus さん、ご回答ありがとうございます。次の状況を処理する方法がまだわかりません。

この Web サイトは、CustomerRegistered、CustomerPurchasedProduct、CustomerMarkedProductAsFavorite というイベントを発行します。バックエンドの現在のバージョンでは、顧客を表示する必要があり、その購入を表示する必要があります。顧客がお気に入りとしてマークしたものは、そのバージョンのシステムには関係ありません。したがって、バックエンドは CustomerRegistered と CustomerPurchasedProduct のみをサブスクライブします。

ここで、マーケティング部門は、お気に入りの製品に関する情報を顧客の詳細ページに表示することも望んでいます。バックエンドは CustomerMarkedProductAsFavorite をサブスクライブしていないため、この情報はバックエンドでは利用できません。その情報はどこから入手できますか?

4

2 に答える 2

7
  1. 各システムは、独自のイベントを保存します。各システムは独自の CQRS システム、または少なくとも独自の自己完結型サービスであるため、独自のデータを管理します。
  2. 各システムは、そのイベントもサービス バスに発行します。このサービス バスは、これらのイベントを保存する場所を決定します。通常、これはトランザクション キューイング システムにあります。
  3. 各システムは、消費する外部イベントをサブスクライブします。これらの受信イベントは保存せず、それらの結果として発生する独自のイベントのみを保存します。サービス バスは、受信イベントを消費するときに、そのサービスの受信キューからイベントを削除できることを認識します。

あなたの余分な質問に対応するために編集してください：

別のアプリケーションが突然追加情報に関心を持つようになった場合、現在関心のあるイベントにリスナーを追加する必要があります。

さらに、これらのイベントのすべてのソースは、これらのイベントを再生できます。リプレイは、このようなシナリオを可能にするイベント ドリブン システムの強力な機能です。そのため、イベント ソースは、選択されたイベント (たとえば、過去 6 か月のすべての CustomerMarkedItemAsFavorite イベント) のみを再生します。これらのイベントを既に消費したシステムは、再生されたイベントが「古い」イベント (つまり、既に処理されたもの) であることを認識し、それらを無視する必要があります。

このようにして、他のサブシステムからの追加情報を使用するように更新されたサブシステムは、その情報を取得し、1 回のバッチ操作ですべてを最新の状態にすることができます。

于 2011-06-04T20:54:37.653 に答える
0

あなたの編集を WRT: 履歴の CustomerMarkedProductAsFavorite データにもアクセスすることは本当に必要ですか? バックエンドを変更して新しいデータをサブスクライブすると、それが前進します。本当に必要な場合は、欠落しているデータを別の問題として埋め戻す方法を考え出すことができます。

Roy は、CustomerMarkedProductAsFavorite データを将来バックフィルすることを保証する 1 つの可能なアーキテクチャをすでに概説しています。

于 2011-06-05T09:14:41.970 に答える