上記のシナリオはすべてのイベント ソーシング ライブラリに適用されます。この上に使用できるインフラストラクチャ コードはありますか?それとも独自に作成する必要がありますか?
イベントに関連付けられた投影メカニズムの概念は、確かに一般的です。残念ながら、スタック、パフォーマンス要件、スケール、およびその他の多くの要因に応じて、それを処理する方法は多数あります。
その結果、私はこのような性質のコモディティ化された施設を知りません。
GetEventStore ストアには統合された Projection 機能があり、これは非常に強力に見え、テーブルからすべてを構築する必要がありません。その存在の前に、私は JOES の SRP らしさを無視することさえ考えるべきではないと主張したでしょう。
Azure について言及する以外に、実際のスタックについて多くを語っていません。
Windows Service Bus では、イベント ストアのシーケンス番号を Service Bus のシーケンス番号と結合するにはどうすればよいですか?
ストリーム ID + コミット シーケンス番号を使用できますMessageId(これを使用して、重複がバスによって確実に削除されるようにします)。メッセージ メタデータにはプロパティも含めることになるでしょう。
既に受信したイベントを安全な方法で検出して処理するためのベスト プラクティスは何ですか (メッセージ ハンドラーの失敗から保護します)。
Azure を使用していて、ServiceBus を検討している場合は、トピックを使用して、少なくとも 1 回の配信を保証できます (そして、セッション機能を使用します)。2 時間のディープダイブ ClemensV サブスクライブ ビデオと他のいくつかのエピソードを視聴しないと、同じ時間をミスに費やすことになります)
ブロードキャスト トラフィックを抑えるために、ContextC が ContextA と ContextB からのリプレイを要求した場合、これらのリプレイ メッセージを ContextC だけに送信する方法はありますか? それとも、これについて心配する必要はありませんか？
ム。あなたはこれが良いアイデアかどうかを尋ね始めましたが、今ではそれが進むべき道であるという仮定に固執しているようです.
第一に、このインフラストラクチャは再発明するための大きな車輪です。単純に BC ごとにトピックを設定し、聞く必要がある人に聞いてもらうことを検討しましたか?
ここで重要なことは、BC が相互にイベントを消費する必要があるという理由だけで、どこにでもあるこの中央の魔法のバスがすべてをどこにでも届けるという事実を心に留めておく必要があるということです。
編集: 質問の編集バージョンへの回答 2+
Windows Service Bus 1.0 では、イベント ストアのシーケンス番号を Service Bus のシーケンス番号と結合するにはどうすればよいですか?
イベント ストアにシーケンス番号がありません。アグリゲートごとにコミット シーケンス番号があります。通常、セッション トピックとサブスクリプションを使用します。次に、グローバルな順序付け (単一のセッション ID を使用) を行うか、集計ごとの順序付け (ストリーム ID をセッション ID として使用) を行うかを選択する必要があります。
イベントがトピックになるMessageSequenceNumberと、サブスクリプション (セッションの場合) がそれらを順番に配信 (実際にはサブスクライバーが受信) します。
既に受信したイベントを安全な方法で検出して処理するためのベスト プラクティスは何ですか (メッセージ ハンドラーの失敗から保護します)。
これは、サービス バス (または任意のキューイング メカニズム) に組み込まれています。正常に処理されるまで、メッセージを完了としてマークしません。失敗すると、放棄につながります (再処理のためにキューに戻されます)。
サブスクライバーが休憩を取ったり、接続が切断されたり、作業がバックアップされたりすることは、トピックによって自然に処理されます。