不知道如何缩短那个头衔。
我基本上试图围绕CQRS（http://en.wikipedia.org/wiki/Command-query_separation）和相关概念的概念。
虽然CQRS不一定包含消息传递和事件源，但它似乎是一个很好的组合（可以看到很多结合这些概念的示例/博客）
给出状态更改的用例（例如更新SO上的问题），您是否会认为以下流程是正确的（如最佳实践中）？
系统发出一个聚合UpdateQuestionCommand，它可能被分成几个较小的命令：UpdateQuestion，它针对Question Aggregate Root，以及UpdateUserAction（计算点数等），以针对User Aggregate Root。这些是使用点对点消息传递异步发送的。
聚合根做他们的事情，如果一切顺利，分别是QuestionUpdated和UserActionUpdated，其中包含外包到Event Store的状态..要保留yadayada，只是为了完成，不是真的有点这里。
这些事件也会放在发布/订阅队列中进行广播。任何订阅者（其中可能有一个或多个创建读取视图的投影仪）都可以自由订阅这些事件。
一般性问题：确实是最佳实践，命令是点对点通信（即：接收器是已知的）而事件是广播的（即：接收器是未知的）？
假设上述情况，允许通过pub / sub而不是点对点广播命令的优点/缺点是什么？
例如：在使用Saga（http://blog.jonathanoliver.com/2010/09/cqrs-sagas-with-event-sourcing-part-i-of-ii/）播放命令时可能会出现问题，因为佐贺需要在其中一个聚集根失败的情况下发挥作用的调解作用受到阻碍，因为传奇不知道哪个聚合根开始参与。
另一方面，我看到允许广播命令的优点（灵活性）。
任何帮助清理头脑的人都非常感谢。
答案 0 :(得分：9)
是的，对于Command或Query，只有一个且只有一个接收器（因此您仍然可以进行负载平衡），但对于Events，可能有零个或多个接收者（订阅者）