そのタイトルを短くする方法がわかりませんでした。
私は基本的に、CQRS（http://en.wikipedia.org/wiki/Command-query_separation）の概念と関連する概念に頭を悩ませようとしています。
CQRSは必ずしもメッセージングとイベントソーシングを組み込んでいるわけではありませんが、それは良い組み合わせのようです（これらの概念を組み合わせた多くの例/ブログ投稿で見られるように）
何かの状態変化のユースケース（たとえば、SOに関する質問を更新する場合）を考えると、次のフローは正しいと思いますか（ベストプラクティスのように）？
システムは、いくつかの小さなコマンドに分割される可能性のある集約UpdateQuestionCommandを発行します。QuestionAggregateRootを対象とするUpdateQuestionと、User Aggregate Rootを対象とするUpdateUserAction（ポイントなどをカウントするため）です。これらは、ポイントツーポイントメッセージングを使用して非同期に送信されます。
集約ルートはそれぞれの役割を果たし、すべてがうまくいけば、イベントQuestionUpdatedとUserActionUpdatedをそれぞれ起動します。これらのイベントには、イベントストアにアウトソーシングされた状態が含まれます。
これらのイベントは、ブロードキャスト用のpub/subキューにも配置されます。すべてのサブスクライバー（読み取りビューを作成する1つまたは複数のプロジェクター）は、これらのイベントを自由にサブスクライブできます。
一般的な質問：コマンドがポイントツーポイントで通信される（つまり、受信者が既知である）のに対し、イベントがブロードキャストされる（つまり、受信者が不明である）ことは、実際にベストプラクティスですか？
上記を想定すると、コマンドをポイントツーポイントではなくpub / subを介してブロードキャストできるようにすることの長所/短所は何でしょうか？
例：佐賀（http://blog.jonathanoliver.com/2010/09/cqrs-sagas-with-event-sourcing-part-i-of-ii/）の使用中にコマンドをブロードキャストすると、問題が発生する可能性があります。佐賀は、どの集合ルートが最初に参加するかを知らないため、集合ルートの1つに障害が発生した場合に佐賀が果たす必要のある仲介の役割が妨げられます。
一方で、コマンドのブロードキャストが許可される場合の利点（柔軟性）がわかります。
私の頭をきれいにするのにどんな助けでも大歓迎です。