Windows Service Bus 1.0異なるプロセス間の通信に使用しています。各コンテキスト イベント ストリームはトピックとしてバス上に存在します。
Service Bus を使用して、境界付けられたコンテキスト間でイベントをリンクする 境界付けられたコンテキストがオンラインに戻ったときに、イベントを同期する (つまり、過去のイベントの再生を要求する) メソッドが必要ですが、戻ってくるメッセージの潜在的なフラッドを制限したいだけです。少なくとも、これが既存の Service Bus 機能を使用して簡単に実行できるものである場合は、それを要求したエンドポイントに送信します。
したがって、架空の ContextC がメッセージを送信して、ContextA と ContextB からの以前のすべてのイベントを要求する場合、これらのリプレイ メッセージを ContextC だけに送信する方法はありますか?
上記のユニキャスト再生を容易にするために、コンテキストをトピックの所有者 (つまり、バストピックへの個々のバスサブスクライバー) にマップする最良の方法は何でしょうか?
私の世界では、私はこれらのものを疎結合に保ちます - 各コンテキストがトピックに何かを置き、それを必要とする人は誰でもサブスクライブします.
各 SB サブスクリプションは、プロパティに基づいて Service Bus のフィルタリング機能を使用できます (たとえば、メッセージにプロパティを追加してイベントにタグを付けてから、ホワイトリストに登録されたクラスのイベントのみが各コンシューマーに適用されることを意味するサブスクリプションにフィルター条件を設定できます)。
それに加えて、すでにトピックごとに分離しているという事実.
サブスクリプションとトピックにより、イベントを処理できるようになります。イベントを失うことも、パブリッシャーがサブスクライバーを心配したり追いかけたりすることもありません。
また、他の質問でこれをイベントストアに関連付けていると述べました-その場合、メッセージを順番に消費する必要がある可能性があります. その場合は、メッセージにセッション ID を付ける必要があります。
このサブスクライバー主導の再配信が必要な理由については推測できますが、今はそうしません。Service Bus を使用してどのように達成するのが最善かを誰かが答える前に、まずその概念と要件を (より高いレベルの目標を説明する質問をすることによって) 説明/検証する必要があります。