我正在研究 CQRS+ES 系统，主要使用轴突框架，但实际上这个问题适用于任何实现。所以我有一个命令处理程序和 1 个或多个事件处理程序，在不同的 JVM、容器等上运行，并且在某些时候这些处理程序中的一个遇到错误。
我们有两种情况，“预期”业务错误和“意外”系统错误。据我了解，我们现在处于异步处理程序中，事件现在是事实，所以实际上我们不能直接回滚这两种情况的命令(因为它可能需要在许多其他预测中回滚它并破坏 CQRS)。
所以我的问题是，这样的错误是否应该在账户分类账中以某种方式“解决”，即通过发送一个新的“逆转”命令，然后以失败事件的方式传播到预测现在解决了吗？
例如，假设我们有一个更新客户信用的命令。该事件已发布，一个投影更新其“总信用”统计信息，另一个投影将更新发布到 UI 的某个 websocket，最后，另一个维护信用状态 - 最后一个处理程序失败。我们是否应该发送回滚业务交易的命令，再次扣除信用，再次更新 websocket 等？如果是轴突，是否有某种方法可以将其捕获为事务？
最佳答案
我要声明，是否采取行动(从而处理命令)的决定应该始终由命令模型/聚合决定。聚合处于处理操作的不正确状态通常会导致“业务异常/错误”。
但是，如果您在事件处理失败时做出决定，那么您就是在事件处理服务中添加了一些决策制定逻辑，而在大多数情况下它可能并不关心。如果这样的事件处理服务更新 View /查询模型，但未能这样做，我认为这不是向聚合发布“补偿命令”以“回滚/撤消事件”的正当理由。
在您的示例中，您有一个“credit-state-maintainer”，我猜它会更新查询模型。因此，我认为处理异常的问题在于服务本身，而不是通过执行补偿操作。
从 Axon 框架的角度来看，您可以将 CreditStateEventHandler 包装在 TrackingEventProcessor 中，并通过调用 TrackingEventProcessor#resetTokens() 在该事件处理器上触发重置 功能。这采取的立场是，您的 CreditStateEventHandler 所导致的异常当然是由于错误编码造成的，否则重播将导致完全相同的异常。
关于java - CQRS/ES - 处理投影错误，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/50594151/