跨越聚合边界的交易答案

【问题标题】：Transactions crossing aggregate boundaries跨越聚合边界的交易
【发布时间】：2015-07-04 06:44:11
【问题描述】：

我有以下域建模问题，我似乎最终会跨越一致性边界或创建一个巨大的聚合。有人可以帮我分解吗？

有两种工作类型JobA、JobB。 JobA 由任务 TaskA 组成。 JobB 由任务 TaskB 组成。 JobA 和 JobB 不相关。他们之间唯一的共同点是他们都需要设备资源。我原本想创建 5 个可以相互引用的聚合根 - JobA 将引用 TaskA 等等。

我可以将一份工作及其任务放在一个集合中。这是以引入其他开销为代价的，因为任务本身就是复杂的生物。但是，以下限制使我无法使用任一模型。

如果任何任务仍未完成，则无法将作业标记为完成。此检查会导致事务跨越聚合边界（例如，TaskA 和 JobA）。
一个设备不能分配给多个作业。此检查将跨越两个作业聚合。
必须先释放设备，然后才能将作业标记为完成。此事务将跨越设备和作业聚合。

拥有单个聚合会将所有事务放在边界内，但这会使聚合变得不可能大。我错过的所有这些中是否隐藏着不同的模型？

【问题讨论】：

有些规则在实际中无法做到强一致，最终必须做到一致。

标签： transactions domain-driven-design domain-model aggregateroot

【解决方案1】：

我认为最好的解决方案可能是使用最终一致性。

当我对设计聚合门有疑问时，我总是看Effective Agreggate Design by Vaughn Vernon。

【讨论】：

这也是我一直在使用的:)。但无法从那里找到解决方案。也许我错过了一些东西。我考虑过最终的一致性，但问题是一个人在完成当前工作之前不允许转移到新工作。并且该作业是工作流的一部分，因此所有任务必须在标记为完成时完成 - 不允许它们在任何时候发生不同步。
我认为你什么都没有。我认为这取决于业务角度，他们是否容忍工作在短时间内不同步。
@341008 很好奇你在这里做了什么以及为什么。这种情况是双向的。

【解决方案2】：

我知道这个问题已经很老了，但我认为您绘制的架构和一致性要求没有任何问题：

作业必须有一个包含其状态的任务列表。当任务在自己的事务中完成时，它会发送 TaskCompleted 事件/消息，然后 Job 将其拾取并在内部更新任务状态。这样，Job 无需检查 Task agregate 即可知道所有任务是否已完成。
必须针对设备聚合执行设备到作业的分配。这将生成 EquipmentAssignedToJob 事件/消息，该事件/消息将由 Job 聚合使用，以使用该作业正在使用该设备的信息更新它自己的状态。设备使用与否都会知道自己的状态。
作业完成操作将释放设备。从作业中释放设备会生成可供设备使用的 JobFinishedUsingEquipment 事件/消息，并且设备状态将更新为未使用。

【讨论】：