cqrs - 在事务中以聚合形式发布事件

Question

我见过一个 CQRS 示例项目，它使用使用 ORM 持久化的有状态聚合根。让我在网络应用程序的上下文中设置问题:

1. 收到请求 - 隐式 session 和 sql 事务开始(每个请求的 session )
2. 根据请求创建和分发命令
3. 命令处理程序使用 repo 加载有问题的 AR，并在 AR 上调用适当的方法
4. 在方法中使用总线引发/发布事件
5. 请求终止——如果管道中没有异常则隐式事务提交

我的问题是围绕事件发布，在隐式事务未能提交的上下文中。在没有更新 AR 的实际状态的情况下发布事件不会是一个大问题吗？如果是这样，如何解决？

Answer 1

在处理 CQRS 和领域事件时，有两件事很重要:幂等性和最终一致性。在这种情况下，您实际上并没有 ACID 事务，您有已处理或未处理的消息。每个消息处理都是独立的(事件不知道命令或其他事件)。 “事务”实际上是对发送的命令的处理。通常事件是命令处理的结果，但“事务”在事件已发布而非处理时结束。

如果服务器崩溃，服务总线/消息处理器应该检测到一个命令没有被发送/处理并且应该尝试重新发送它(这里的幂等性很重要)。与事件处理相同。

在您的示例中，您谈论的是提交(一个以数据库为中心的概念)，但可以有 2 个命令更新不同的 AR 执行异步。如果一个命令失败，另一个命令不知道。这似乎很难处理，但其实很简单，但是在处理最终一致性时，必须对概念和用例进行适当建模。

当从业务角度来看命令失败(违反业务规则)时，将发布一个新事件，其处理程序将发出补偿操作(并不像听起来那么难)。所有感兴趣的各方都将订阅该事件并采取相应行动。

当您对业务流程建模时，您提出了 2-3 个需要被视为事务的命令，您需要了解这些命令之间是否存在业务关系。有些可能无关，但其他实际上可能是传奇的一部分。所以你在一个事务中没有 3 个命令，你有 cmd1 -> event -> cmd 2-> event ->cmd3。只有在最后，“交易”才完成。

业务模型会告诉您是哪种情况(这就是正确建模很重要的原因)，这将帮助您处理问题，因为您不必撤消 3 个命令和 N 个事件。