メッセージバスvメディエーターパターンvインメモリバス
私はこれらのそれぞれをいつ使うべきかを理解するのに苦労しています：
1）メッセージバス：マイクロサービス間で統合イベントを送信するために使用されます。たとえば、マイクロサービスAは、マイクロサービスBおよびマイクロサービスCによって処理される統合イベントをパブリッシュすることができます。 RabbitMQは、マイクロサービスの1つがダウンした場合に後でイベントを処理できるという意味で、耐久性がある可能性があるということです。配送も保証します。
2）Mediatr（メディエーターパターン）：CQRSを使用すると、Mediatrパターンを使用してコマンドとイベントを分離し、MVCコントローラー/サービスを薄くできます。
これらの両方のパターンを同じ環境でどのように使用できるかがわかります。次に、次のようなコードが表示されます。
3）メモリバス： https://github.com/gregoryyoung/m-r/blob/master/SimpleCQRS/FakeBus.cs 。これはインメモリバスです。
Mediatrとインメモリバスの違いは何ですか？現時点で私が考えているのは、オブザーバーパターンを使用する場合はMediatrがより適切であり、パブリッシャー/サブスクライバーパターンを使用する場合はメモリー内バスがより適切であるということです。私はこれを正しく理解しましたか？
単一のマイクロサービス（ドメインイベント用）にインメモリバスを使用し、統合イベント（マイクロサービス間）に耐久性のあるメッセージバスを使用することは適切ですか？
メディエーターパターン は、2つのマイクロサービス間に柔軟な分離インターフェースを作成します。メッセージは各マイクロサービスとの間で送受信されますが、一方が他方の明示的な動作をすべて知っている必要はありません。
このパターンは、2つの関係が将来大きく変わる可能性があると考える場合に理想的です。メディエーターはスタンドアロンである可能性があり、配信が失敗した場合にメッセージを永続化できるため、メッセージバスと同じくらい安定している可能性があります。
publish-subscribeパターン これは基本的にメッセージバスであり、2つのインターフェイスだけのものではありません。それは潜在的に複数のインターフェースのためであり、最大の柔軟性を可能にします。柔軟性はメッセージ自体にも及ぶため、イベントが発生したときに、メッセージの受信に関心のある人なら誰でも簡単にメッセージを送受信できなければなりません。また、メディエーターとは異なり、渡されるメッセージの変更はマイクロサービス全体で一貫して解釈される必要があるため、注意しないとバージョン管理の問題が発生する可能性があります。メッセージが変更されると、すべてが適切に機能するために、メディエーターのみが絶対にmustも更新される必要があります。
インメモリバスは、永続性のないメッセージバスほど実際のパターンではありません。これはより高速ですが、予期しないエラーが発生した場合には理想的ではありません。エラーが発生した場所がわからないため、以前の状態を復元するのが非常に困難です。本番環境では、ログファイルに書き込んだとしても、これはお勧めしません。
それがあなたの質問に答えることを願っています！