我正在努力解决事件采购中的一种情况。 我有订单拣选系统，可以准备订单。 我注册了订单准备事件，pickedQuantity>requestedQuantity 我问如何在源代码中添加此控件以防止这种情况，我如何刷新所有受影响的订单以便能够重建正确的状态？
请问有什么想法吗？
这就是我之前的源代码
handle(OrderPrepared event) {
OrderLine orderLine = event.getData();
this.pickedQuantity = orderline.getPickedQuantity();
}
添加控件后解决问题
handle(OrderPrepared event) {
OrderLine orderLine = event.getData();
if(orderline.getPickedQuantity <= ordeline.getRequestedQuantity) {
this.pickedQuantity = orderline.getPickedQuantity();
}
}
这样做，将阻止重建聚合状态以附加其他事件
我在事件采购中遇到了一种情况。
不是你的错；文学很糟糕[tm]。
我问如何在我的源代码中添加此控件以防止这种情况
因此，通常业务策略的执行属于您的“命令处理程序” - 也就是决定您添加到历史记录中的事件以及这些事件包含哪些信息的逻辑。
当策略应用不正确时（或当策略发生变化时），我们通常会使数据恢复与策略一致，并向历史记录中添加更多事件以纠正问题。这被正确地认为是实施实际问题域的纠正过程。
例如，在会计领域，当您的条目出现错误时，有一个过程可以引入可逆转错误的行项目和具有正确信息的第二行项目。因此，您可以在命令处理程序中实现该过程，将事件附加到历史记录中。
（抱歉：我对订单拣选系统了解不够，无法知道领域专家如何扭转您所描述的错误。这可能就像删除该订单行然后添加更正的版本一样简单。根据您当地的情况，可能是一两个事件）。
通常，您不应在阅读一系列事件时尝试应用策略。特别是，当我们想要修复历史记录中的错误时，不应该阻止我们将历史记录加载到内存中！
因此，当将信息复制到瞬态内存表示中时，您应该将提供的历史记录视为权威。
可以说，尝试即时重写历史并不是您刚开始时想要遇到的问题。 （如果您遇到这个问题，请参阅Greg Young 的书。）
也就是说，使用根据事件中的信息计算出的值不一定有错。
“生成 Bob 的星期一报告时，第七列应显示 pickedQuantity 和 requestQuantity 的最小值（或零，以较大者为准）”是使用事件作为数据模型满足的完全合理的要求，您可以这样做。
您只需要做得足够好，以便下一个程序员（可能是您，几个月后您已经忘记了微妙的细节）可以快速了解正在发生的事情并扩展代码以满足新需求，而无需承担不必要的风险.