私はパラダイムと、CQRS などの関連するアーキテクチャにかなり慣れていません。このタイプのテクノロジーが適していると思うプロジェクトを開始しました。プロジェクトで EventStore を使用するのは興味深いと思いましたが、ドキュメントを少し読んだところ、EventStore 自体がイベントへのサブスクリプションを許可しているため、EventStore を使用するとメッセージ バスが不要になることがわかりました。これは正しいですか? EventStore の上にバスを実装する利点はありますか?
1808 次
3 に答える
7
メッセージ バスとイベント ストアは、2 つの異なる目的を果たす 2 つの異なるものです。
EventStore (GES) では、クライアント追跡またはサーバー追跡 (競合するコンシューマー) のいずれかのサブスクリプションと、ATOM フィードのロング ポーリングを使用して、イベントをサブスクライブできます。イベントはストリームに編成され、各ストリームには独自の名前が付けられ、このストリームのイベントが含まれます。CQRS と EventSourcing は通常 DDD プロジェクトに適用されるため、ストリームは通常集計を表し、個々のストリームを読み取ることで集計状態を再作成でき、ストリーム カテゴリ (集計タイプ) からのイベントの読み取りがプロジェクション (読み取りモデルの構築) に使用されます。各サブスクライバーは、イベントを読み取る独自のプロセスを制御します。イベントは保存されるため、必要な回数だけ読み取ることができます。
メッセージ バスは、イベントの保存とは関係ありません。エンドポイント間でメッセージを確実に配信することを目的としています。メッセージ バスは通常、ブローカーまたはフェデレーション トポロジと、直接送信、パブリッシュ-サブスクライブ、リクエスト-レスポンスなどのさまざまなパターンをサポートします。メッセージ コンシューマーがメッセージに ACK を送信すると、そのメッセージはキューから削除され、再度読み取ることはできません。公開されるメッセージのサブスクライバーがいない場合、メッセージは永久に失われます。
つまり、どちらも有用なパターンですが、永続化にはイベント ストアが使用され、耐久性のあるキューと信頼性の高い配信にはメッセージ バス/ブローカーが使用されます。
于 2016-10-31T20:34:05.843 に答える
4
私はこのように考える傾向があり、これが私たちが設定した方法です：
メッセージ バス: コマンドおよびイベント ブローカの処理。これは、さまざまなサービス間の通信やイベントのブロードキャストに使用されていました。このコンテキストでの「イベント」は一時的なものです。サブスクライバーがトリガーするためだけに存在します。
EventStore: これは、ドメイン エンティティに対して実行されたアクションを格納するためのものです。このコンテキストでの「イベント」は永続的です。オブジェクトの「状態」を再生して取得するために存在します。
一時メッセージは 1 回だけ起動されてから消費されるため、リプレイできません。EventStore のイベントは永続的/再生可能であり、オブジェクトの状態を取得したり、プロジェクションを構築したりするために再生されます。1 つはブローカーで、もう 1 つはソースです。
物理的にも概念的にも、この 2 つの間に太い線を引き続けてください。
于 2017-09-06T21:40:46.367 に答える