我对事件外包不熟悉，但是对于我们当前的项目，我认为它是一个非常有前途的选择，主要是因为审计跟踪。
我不满意100％的一件事是缺乏跨聚合交易。请考虑以下问题：
我有一个order，可以在不同站点的各种机器上进行处理。我们有containers，工人将order放入其中并在机器之间搬运。
跟踪必须通过containers（具有唯一的条形码ID）完成，order本身无法识别。问题是：containers被重用并且需要被锁定，所以没有工人可以同时在同一个container中放置两个orders（为简单起见，假设他们不能看看容器内是否已经有订单）。
为清晰起见，请从高层次查看：
“将Order A从Container 1移到Container 2”是我正在努力解决的问题。
这是事务中应该发生的事情（不存在）：
如果应用在位置1或位置2之后崩溃，则我们的容器已被锁定且无法重复使用。
我想到了多种可能的解决方案，但是我不确定是否有更优雅的解决方案：
还有其他我能做的吗？
我认为是明智的选择，但是我们将有一个REST API，我们可以在其中获得命令从容器1到2的转移订单A，这意味着API命令处理程序将需要侦听事件流，并等待一些传奇生成的事件将200发送给请求者。我认为这不是好的设计，是吗？
不使用事件源进行跟踪也不是完美的，因为容器可能会影响订单的质量，因此订单也必须跟踪使用过的容器。
谢谢您的提示。
聚合之间的一致性最终是可能的，这意味着很可能是AR1更改了其状态，Ar2无法更改其状态，现在您应该恢复AR1的状态以使系统进入一致状态。1）如果这种情况经常发生，并且恢复确实很痛苦，请重新调整您的AR边界。2）手动恢复。不要使用saga，不要将其用于此类目的。如果您的传奇人物想补偿AR1，但其他交易已将其状态更改为另一笔补偿将失败。