CQRS +事件采购:(这是正确的)命令通常是点对点通信,而域事件是通过pub/sub传递的吗？

Question

不知道如何缩短那个头衔.

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

虽然CQRS不一定包含消息传递和事件源,但它似乎是一个很好的组合(可以看到很多结合这些概念的示例/博客)

给出状态变化的用例(例如更新SO上的问题),您是否会认为以下流程是正确的(如最佳实践)？

• 系统发出一个聚合UpdateQuestionCommand,它可能被分成几个较小的命令:UpdateQuestion,它针对Question Aggregate Root,以及UpdateUserAction(计算点数等),针对User Aggregate Root.这些是使用点对点消息传递异步发送的.

• 聚合根完成他们的事情,如果一切顺利,火灾事件QuestionUpdated和UserActionUpdated分别包含外包到事件存储的状态..要保持yadayada,只是为了完整,这不是真正的重点.

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

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

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

例如:在使用Saga(http://blog.jonathanoliver.com/2010/09/cqrs-sagas-with-event-sourcing-part-i-of-ii/)播放命令时可能会出现问题,因为佐贺需要在其中一个聚合根失败的情况下发挥调解作用,因为传奇不知道哪个聚合根开始参与.

另一方面,我看到允许广播命令的优点(灵活性).

任何帮助清理头脑的人都非常感谢.

Answer 1

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