EventSourcing中的多聚合交易

汤玛士

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

我不100%满意的一件事是缺少聚合跨度的事务。请考虑以下问题:

我有一个在不同站点的各种机器上处理订单而且我们有容器供工人下订单,然后将其从一台机器运送到另一台机器。

跟踪必须通过容器容器具有唯一的条形码ID)完成,订单本身无法识别。问题是:容器被重用并且需要被锁定,因此没有工人可以同时在同一个容器放置两个订单(为简单起见,假设他们看不到容器内是否已有订单)。

为了清楚起见,从较高的角度来看:

  • 订单A已创建
  • 放置在容器1上的订单A
  • 容器1移至机器A并进行扫描
  • 机器A为订单A生成一些事件
  • 订单A从容器1移至容器2
  • 订单B已创建
  • 订单B放在容器1上...

我正在努力“将订单A从容器1移至容器2”。

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

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

如果应用在位置1或位置2之后崩溃,则说明我们的容器已锁定且无法重复使用。

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

  • 假设它每周不会失败超过一次,并提供了一种工人可以手动修复的方式。
  • 将容器跟踪视为另一个域,不要在该域中使用事件源。
  • 用补偿措施和其他东西实施传奇。

我还能做些什么吗?

我认为应该顺其自然,但是我们将拥有一个REST API,从容器1到2获得命令传输顺序A,这意味着API命令处理程序将需要侦听事件流,并且等待一些传奇事件将200发送给请求者。我认为这不是好的设计,是吗?

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

谢谢您的提示。

德米特里·鲍迪

聚合之间的一致性最终是可能的,这意味着很可能是AR1更改了其状态,Ar2未能更改其状态,现在您应该将AR1的状态还原为使系统进入一致状态。1)如果这种情况经常发生,并且恢复确实很痛苦,请重新调整您的AR边界。2)手动恢复。不要使用传奇,它们不应用于此类目的。如果您的传奇人物想补偿AR1,但其他交易已将其状态更改为另一笔,则补偿将失败。

本文收集自互联网,转载请注明来源。

如有侵权,请联系 [email protected] 删除。

编辑于
0

我来说两句

0 条评论
登录 后参与评论

相关文章