我在申请之前对其进行了一些研究（或不是）。
快速提问：使用EventSourcing模式时，我们可以想象这个场景可以处理一个事件：
我们可以重播所有事件并重建业务对象状态。
如何处理业务逻辑错误（业务逻辑算法v1包含令人讨厌的错误）。
我看到我们可以修复错误并重播事件，然后我们再次将商业模式置于有效状态。
但是，如果在应用事件＃1时修复业务规则会导致'futurs'命令失败，会发生什么？换句话说，事件＃2，事件＃3，事件#n在应用事件＃0之后依赖于域模型的状态。我们如何修复级联事件失败？
我没有特定的用例：但我们可以设想一个平衡目前为正的帐户。应用事件＃0会增加余额，但这是一个错误，开发人员希望减少余额。事件＃1是因为此时的正余额而有效的购买。
开发人员修复错误并重播事件。事件＃0减少余额变为负值。重播事件＃1：会发生什么？
我们是否需要通过“补偿”处理此案例？如何处理？
提前感谢您的意见，外部资源可以提供任何帮助（文章，博客）。
再见
答案 0 :(得分：4)
小修正
使用EventSourcing模式时，我们可以想象这个场景可以处理事件
命令处理程序（特别是反腐败层）负责确保命令格式正确。业务模型决定业务是否允许该命令。
好消息：事件只是状态变化;所有规则验证都已完成。当您修复域对象中的错误以便它生成响应命令的正确事件时，您不会更改事件的应用方式。
你肯定没有改变历史 - 如果ATM没有提供20美元，你就不能通过编辑记录来获得回报。
这意味着部署错误修复可以防止问题恶化;但它对于不正确的事件历史没有任何作用。
补偿事件是正确的答案。曾经有一个杂货店员双扫一个项目，并且必须退出其中一个吗？仔细观察，你会看到所有三个项目
这是补偿事件附加到流末尾的习语。
因此，如果错误显示首先出现在事件＃0中，然后[事件＃1 ..事件＃99]已经播放，则错误的补救措施是发布补偿事件＃100。 / p>
请注意，这正是簿记员所做的事情。你在第1行的条目上添加了错误的符号，添加了更多的条目，意识到你的错误，并添加了一个补偿早期错误的新条目。
更多好消息：在成熟的业务流程中，已经有适当的缓解程序来处理各种突发事件。因此，您可以与您的领域专家会面，并在白板上涂鸦解释问题，您的专家应该能够向您展示正确的补偿方法。之后的一切都是功能管理（缓解是否需要自动化？系统是否需要自动进行缓解，还是让人类专家告诉它应用缓解措施等等。）