CQRS +イベントソーシング：（それは正しいですか）コマンドは一般にポイントツーポイントで通信されますが、ドメインイベントはpub / subを介して通信されますか？

私は基本的に、CQRSの概念と関連する概念に頭を包み込もうとしています。

CQRSには必ずしもメッセージングとイベントソーシングが組み込まれているわけではありませんが、適切な組み合わせのようです（これらの概念を組み合わせた多くの例/ブログ投稿でわかるように）

何かの状態変更のユースケース（SOに関する質問を更新するなど）が与えられた場合、次のフローが正しいと考えますか（ベストプラクティスとして）。

システムは、いくつかの小さなコマンドに分割される可能性のある集約UpdateQuestionCommandを発行します。質問集約ルートをターゲットとするUpdateQuestion、およびユーザー集約ルートをターゲットとするUpdateUserAction（ポイントをカウントするなど）。これらは、ポイントツーポイントメッセージングを使用して非同期的に送信されます。

集約ルートはそれぞれの処理を実行し、すべてがうまくいけば、QuestionUpdatedイベントとUserActionUpdatedイベントをそれぞれ起動します。これらのイベントには、イベントストアに外部委託された状態が含まれます。

これらのイベントは、ブロードキャスト用のpub / subキューにも置かれます。サブスクライバー（読み取りビューを作成する1つまたは複数のプロジェクターの可能性が高い）は、これらのイベントを無料でサブスクライブできます。

一般的な質問：コマンドはPoint-to-Pointで通信される（つまり、受信者が既知である）のに対して、イベントはブロードキャストされる（つまり、受信者が不明である）ことは本当にベストプラクティスですか？

上記を仮定すると、ポイントツーポイントではなくpub / subを介してコマンドをブロードキャストすることの利点/欠点は何でしょうか？

例：佐賀はどの集約ルートが最初に参加するのかわからないため、集約ルートの1つに障害が発生した場合に佐賀が果たす必要がある調停の役割が妨げられるため、佐賀の使用中にコマンドをブロードキャストすることが問題になる可能性があります。

一方、コマンドのブロードキャストが許可されると、利点（柔軟性）が得られます。

免責事項：私はCQRSの世界で最初の一歩を踏み出しているだけですが、問題に関する現在の理解を提供することができ、他の人が確認するかどうかを確認できます。以下に書いているものはすべて、根底にある「見たとおり」のテーマを持ち、権威がありません。

80％の場合

あなたの質問に答えるために、コマンドは確かにポイントツーポイントの問題です。コマンドがコントローラー（MVC webapp）に入ると、そのコントローラーはコマンドディスパッチャーに適切なコマンドハンドラーを1つだけ見つけてもらい、そのハンドラーに作業を委任します。

なぜ公開しないのですか？

それは責任の問題です。何かがコマンドを送信する場合、それが満たされることを期待する必要があります。単に公開して、どこかでそれが取り上げられて行動することを望んでいる場合、これが当てはまるという保証はありません。外挿では、複数のハンドラーがコマンドに作用することを決定していないかどうかもわからないため、同じ変更が複数回適用される可能性があります。

一方、イベントは本質的に情報を提供するものであり、特定のイベントに関心のあるコンポーネントがゼロ、2つ、またはそれ以上であることを期待するのは合理的です。私たちは、要求された変更を行う範囲を本当に気にしません。

例

これは実際の生活と比較できます。子供が3人いる場合、部屋に入って「バスルームを掃除してください」と叫ぶだけで、誰かがそうするという保証はありません。あなたがしたいことをするために特定の子供を割り当てた場合、より良い運賃。

しかし、その子供が仕事を終えたとき、「バスルームは掃除されました」と叫ぶと便利です。そうすれば、歯磨きをしたい人なら誰でもできるようになります。

私は通常、開始システムがコマンドが複数のターゲットシステムによって処理されることを決して期待しないことに同意します。

• コマンドは通常、決して「送信と祈り」です-コマンドの開始系は、一般的に取るコマンドの進捗状況や成果などの非同期のフィードバックを望んでいる場所（例えば状態イベントが好きacknowledgement、そして成功したcompletionかfailure、開始を知らせるために標的化さシステムによって公開することができますシステム）。
• 複数のターゲットシステムが関与している場合、開始システムはコマンドの複数の（おそらく矛盾する）結果を受け取ります（たとえば、ターゲット1は成功したが、ターゲット2は失敗しました）。これには、元のコマンドの実際の状態を決定する際に追加の複雑さが必要になります（たとえば、コマンドトランザクションは、すべてのターゲットが成功した場合にのみ成功と見なされますか？等。）。これにより、開始システムとターゲットシステムの間に望ましくない結合と複雑さが生じます。

ただし、システム間で発行されたコマンドを「盗聴」する追加の（非トランザクション型で、通常はかなり「無差別」な）コンシューマーをサブスクライブできるメリットはあります。

• 監査目的
• インスツルメンテーションおよび運用メトリック（負荷、ビジネス分析など）
• 複雑なイベント処理またはストリームイベント処理「盗聴者」-これらのシステムは、コマンドのエラーまたは不規則性（コマンドの頻度、コマンドとイベントのさまざまな組み合わせ間の相関関係）を検出し、アラートまたは修正アクション（多くの場合、さらに、さまざまなタイプのコマンドの形式）。