EventSourcing中的多聚合事务

Question

我是新的事件来源，但对于我们目前的项目，我认为这是一个非常有希望的选择，主要是因为审计线索。

有一件事我不能百分之百满意，那就是缺乏全面的超越。请考虑以下问题：

我有一个订单，它在不同的站点在不同的机器上进行处理。我们有容器，，工人们把订单放进去，然后从一台机器搬到另一台机器。

跟踪必须通过containers (它具有唯一的条形码-id)进行，order本身是不可识别的。问题是：容器被重用并需要锁定，因此没有工人可以同时在同一个容器中放置两个orders (为了简单起见，假设它们无法查看容器中是否已经有订单)。

为了清晰起见，高层次视图：

• Order A created
• Order A放在容器1
• Container 1上移动到机器A并获取scanned
• Machine A为A订单生成一些事件，从 Container 1移动 Order A到Container 2
• Order B created
• Order B on <1
• Container>E 2471.H 248F 249

“将Order A从Container 1移动到Container 2”是我正在努力解决的问题。

这就是在事务中应该发生的事情(不存在)：

1. Container 2：LockAquiredEvent
2. Order A：PositionChangedEvent
3. Container 1：LockReleasedEvent

如果应用程序崩溃后，位置1或位置2，我们有容器是锁定的，不能再使用。

我想到了多种可能的解决方案，但我不确定是否有更优雅的解决方案：

domain.

• Implement
• 假设它每周不会失败一次，并提供了一种工人可以手动修复的方法。
• 将容器跟踪看作是一个不同的域，并且不使用事件源，这是一个带有补偿行为的传奇故事。

还有什么我能做的吗？

我认为这是最好的方法，但是我们将有一个rest，在这里我们可以从容器1到容器2获得命令传输命令A，这意味着api命令处理程序需要侦听事件流，并等待某个saga生成的事件向请求者传递200。我不认为这是好的设计，是吗？

不使用事件源进行跟踪也不完美，因为容器可能会对订单的质量产生影响，因此订单也必须跟踪使用过的容器。

谢谢你的暗示。

Answer 1

聚合之间的一致性是最终的，这意味着AR1更改了它的状态，Ar2没有改变它的状态，现在您应该恢复AR1的状态，使系统进入一致的状态。1)如果这种情况经常发生，而且复苏真的很痛苦，那么就重新建立你的AR边界。2)人工恢复。不要使用佐贺的，它们不应该被用于这样的目的。如果您的传奇想要补偿AR1，但是其他事务已经将其状态更改为另一个，则补偿将失败。