EventSourcing 中的多聚合事务

Question

我是事件溯源的新手，但对于我们当前的项目，我认为它是一个非常有前途的选择，主要是因为审计跟踪。

我不是 100% 满意的一件事是缺乏聚合跨度交易。请考虑以下问题：

我有一个订单，它在不同站点的不同机器上处理。我们有容器，工人将订单放入其中并从一台机器运送到另一台机器。

必须通过容器（具有唯一的条形码ID）进行跟踪，订单本身无法识别。问题是：containers是复用的，需要加锁，所以没有worker可以同时在同一个container下放两个order （为简单起见，假设他们看不到容器内是否已经有订单）。

为清楚起见，高级视图：

• 订单已创建
• 订购放在容器 1 上
• 容器 1 移动到机器 A 并被扫描
• 机器 A 为订单 A 生成一些事件
• 将 Order A 从 Container 1 移动到 Container 2
• 订单 B已创建
• 订单 B放在容器 1 ...

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

这是交易中应该发生的事情（不存在）：

1. 容器 2：LockAquiredEvent
2. 订单 A：PositionChangedEvent
3. 容器 1：LockReleasedEvent

如果应用程序在位置 1 或位置 2 后崩溃，我们的容器已被锁定且无法重复使用。

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

• 假设它每周故障不会超过一次，并提供一种方法可以让工作人员手动修复它。
• 将容器跟踪视为不同的域，不要在该域中使用事件溯源。
• 用补偿动作和​​其他东西来实现一个传奇。

还有什么我可以做的吗？

我认为传奇的事情是要走的路，但我们将有一个休息 api，在那里我们得到一个命令将订单 A 从容器 1 转移到 2，这意味着 API 命令处理程序需要监听事件流并等待一些 saga 生成的事件将 200 传递给请求者。我不认为这是一个好的设计，是吗？

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

感谢您的任何提示。

Answer 1

聚合之间的一致性是最终的，这意味着很可能是 AR1 改变了它的状态，Ar2 没有改变它的状态，现在你应该恢复 AR1 的状态以使系统进入一致状态。 1）如果这种情况经常发生并且恢复真的很痛苦，请重新定义您的 AR 界限。 2) 手动恢复。不要使用 saga，它们不应该用于此目的。如果您的 saga 想要补偿 AR1，但其他事务已经将其状态更改为另一个，则补偿将失败。