私は、イベント駆動型アーキテクチャのバリエーションと呼ばれるこの記事を読んでいて、メディエーターとブローカーの両方のトポロジーを示しています。
記事によると、メディエータのトポロジは次のようになります。
イベント フローは、クライアントがイベントをイベント キューに送信することから始まります。イベント キューは、イベントをメディエーターに転送するために使用されます。イベント メディエーターは初期イベントを受信し、追加の非同期イベントをイベント チャネルに送信してプロセスの各ステップを実行することで、そのイベントを調整します。イベント チャネルでリッスンするイベント プロセッサは、イベント メディエーターからイベントを受信し、特定のビジネス ロジックを実行してイベントを処理します [...] イベント メディエーターは、必要なビジネス ロジックを実際には実行しないことに注意してください。最初のイベントを処理するのではなく、イベントを処理するために必要な手順を知っています [...] イベント チャネルは、メッセージ キューまたはメッセージ トピックのいずれかです。
そのため、私はこの図を調べて、特定のプロセッサーが特定のイベントの処理を終了したことをメディエーターがどのように判断して、プロセスの次のステップを調整できるかを理解しようとしていました。
それが言うとき、記事は十分に明確ではありません
初期イベント ステップごとに、イベント メディエータは処理イベントを作成し、その処理イベントを送信して、対応するイベント プロセッサによって処理イベントが処理されるのを待ちます。このプロセスは、最初のイベントのすべてのステップが処理されるまで続きます。
これで、通信が非同期であり、イベント メッセージがメッセージ キューを通過するという点でこの記事は明確ですが、図には、イベント プロセッサから出てメディエータに戻るイベントは示されていません。
この記事では、メディエータはイベント プロセッサが終了するまで待機すると述べていますが、これがアーキテクチャの観点からどのように行われるのかは明確ではありません。
非同期のキューベースの RPC (例: Rabbit RPC ) ですか、それともどこかで非同期応答を待っている別のリスナーがありますか?
アーキテクチャの観点からこれをどのように実装できるかについて何か考えはありますか?