システムのメッセージフローを設計する際に、どの方法を検討するのか少し問題があります。Nサービスバス - コンテンツベースのルーティングと監査 - 私のアプローチは大丈夫ですか？
弊社のビジネスプロセス（貨物費の計算）が揮発性であるため、プロセスを即座に変更できるようにワークフローフレームワークを使用しています。
一般的なプロセスは、インタフェースは、顧客が（、あなたはそれに名前を付けるWebサービス、TCPエンドポイント、データベース・ポーリング、ファイル）を提供どんなインターフェースを介して顧客システムに接続するサービスであり、この
ようになるはずです。次に、受信したデータと実行されるワークフローのIDを含むコマンドがエグゼキュータに送信されます。
最初の問題は、複数のワーカーサービスに負荷を分散したい時点にあります。
小包ラベルの印刷、価格の計算、通知メールの送信など、さまざまなプロセスがあるとします。大量のメールワークフローが実行されるため、ラベルの印刷はとなることはありません（）。だから私たちは、彼らがしている仕事に基づいて、別の労働者にコマンドを送ることができるようにしたい。
すべてのコマンドは「ワークフローXYを実行する」のようなものなので、独自のコンテンツベースルーティングを実装する必要があります。 NServicebusはこれをそのままの形でサポートしていません。ほとんどの場合、アンチパターンです。
が異なるメッセージタイプを使用してメッセージをルーティングできない場合は、これを行うより良い方法はありますか？
第2の問題は、監視を追加したい場合に発生します。エンドポイントはメッセージタイプごとに1つのキューにのみ登録できるため、すべてのエグゼキュータが「ワークフローを完了しました」というメッセージを発行することはできません。現在の解決策は、あらかじめ設定された監査エンドポイントへのメッセージBus.Sendになります。 ）
複数のワーカーの公開メッセージを1つのキューに再度統合する方法がありますか？ ＃1の問題がなければ、すべての作業者が同じ入力キューを使用できると思いますが、このシナリオではこれは不可能です。
いいね！このようにして、メッセージ自体はルーティング関連のデータで「汚染」されず、メッセージをどのワーカーにルーティングするかを簡単に追跡または変更できます。 – Zebi
これはまさにあなたがやりたいことです。あなたのメッセージを「純粋」かつビジネス指向に保ち、処理/輸送に関連するすべての側面にヘッダーを使用します。それはあまり正確ではありませんが、あなたのメッセージは「何」で、あなたのヘッダーは「どのような」ものであるかはある程度までわかります。 –
NSBがヘッダーを完全にサポートしているので、この作業は簡単に達成できるはずです。 –