publish-subscribe - CQRS + 事件溯源 : (is it correct that) Commands are generally communicated point-to-point, 而领域事件通过发布/订阅进行通信？

Question

不知道如何缩短这个标题。

我基本上试图围绕 CQRS (http://en.wikipedia.org/wiki/Command-query_separation) 和相关概念的概念。

尽管 CQRS 不一定包含消息传递和事件溯源，但它似乎是一个很好的组合(从结合这些概念的许多示例/博客文章中可以看出)

给定某个状态更改的用例(比如更新关于 SO 的问题)，您是否认为以下流程是正确的(如最佳实践中那样)？

系统发出一个聚合的 UpdateQuestionCommand，它可能被分成几个更小的命令:针对问题聚合根的 UpdateQuestion 和针对用户聚合根的 UpdateUserAction(计算点数等)。这些是使用点对点消息传递异步发送的。

聚合根做他们的事情，如果一切顺利，分别触发事件 QuestionUpdated 和 UserActionUpdated，其中包含外包给事件存储的状态......要持久化 yadayada，只是为了完成，不是真正的重点。

这些事件也放在发布/订阅队列中进行广播。任何订阅者(其中可能有一个或多个创建阅读 View 的投影仪)都可以自由订阅这些事件。

一般问题:命令是点对点通信(即:接收器已知)而事件是广播(即:接收器未知)确实是最佳实践吗？

假设上述情况，允许通过 pub/sub 而不是点对点广播命令的优点/缺点是什么？

例如:在使用 Saga 时广播命令 (http://blog.jonathanoliver.com/2010/09/cqrs-sagas-with-event-sourcing-part-i-of-ii/) 可能是一个问题，因为Saga 在其中一个聚合根失败的情况下需要发挥的中介作用受到阻碍，因为 saga 不知道从哪个聚合根开始参与。

另一方面，当允许广播命令时，我看到了优势(灵活性)。

非常感谢任何帮助清理我的头脑。

Answer 1

是的，对于 Command 或 Query 只有一个且正好是一个接收器(因此您仍然可以进行负载平衡)，但对于 Events 可能有零个或多个接收器(订阅者)