domain-driven-design - DDD 用两个聚合中的不变量修改每个事务的一个聚合

Question

假设我有一个聚合根 租户 和一个聚合根 组织 。多个 组织 可以链接到单个 租户 。 租户 在其聚合中仅具有 组织 的 Id 。

假设我在 组织 聚合中有以下不变量: 组织 只能有一个特定产品类型的订阅。

假设我在 租户 聚合中具有以下不变量:与租户相关的所有 组织 中必须仅存在一个产品类型订阅。

我们如何使用每个交易规则的一个聚合来强制执行这些不变量？
向 组织 添加订阅时，我们可以轻松验证第一个不变量，并触发域事件以更新(最终一致性) 租户 ，但是如果不变量在 租户 聚合中被违反会发生什么？

这是否意味着触发另一个域事件以回滚 组织 聚合中发生的情况？在成功修改第一个聚合后将响应发送到 UI 的情况下，这似乎很棘手。

或者这里的真正方法是在启动更新之前使用域服务来验证两个聚合的不变量？如果是这样，我们是将不变量/规则直接放在域服务中，还是将某种 bool 验证方法放在聚合上以保持逻辑在那里？

更新
如果违反了一个不变量，UI 必须阻止用户保存在 UI 中怎么办？在这种情况下，我们甚至不会尝试更新聚合。

Answer 1

您可能需要考虑的一件事是您的领域中可能缺少一个概念。您可能想要探索您的方案是否有可能将某些内容作为订阅计划概念，它本身就是一个聚合并强制执行您当前尝试放入租户/组织聚合中的所有这些规则。

面对这样的场景时，我往往会想“如果根本没有促进这种操作的系统，组织会做什么”。在您的情况下，如果来自同一个租户的多个人，每个人都负责一个组织......他们将如何同步他们的订阅以符合不变量？

在这样的练习中，您可能会遇到一些已经探索过的场景:

举办聚会事件(例如电话 session )以确保没有进行多余的订阅:这就是域服务路径。

每个人都进行自己的订阅并相互通知，最终收回多余的订阅:这就是事件 + 回滚路径。

他们可能会妥协并保留一个共享的分类帐，在那里他们可以检查订阅在公司范围内的进展情况，分类帐是此类决策的权威:这就是缺少的聚合路径。

如果你足够强调这个问题，你可能会找到其他选择。