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