DDD事务约束：跨Tenant与Organization聚合根的不变量如何处理？

这绝对是DDD实践中让人挠头的跨聚合不变量问题——既要守着「单事务只改一个聚合根」的原则，又要保证两个聚合的规则不冲突。我来分享几个实际项目里用过的靠谱方案：

DDD中聚合的核心使命就是封装不变量，跨聚合的强规则冲突往往暗示当前的聚合划分可能有优化空间。

你可以考虑把「订阅的全局管控逻辑」划归Tenant聚合根：

• 把创建订阅的入口从Organization移到Tenant，比如给Tenant加一个AddSubscriptionToOrg(orgId, productType)方法。
• 在这个方法里，Tenant先验证自己的不变量：检查旗下所有Org的订阅记录（你可以在Tenant聚合内维护一个轻量的索引，比如productTypeToOrgId映射，避免每次都查所有Org），确保同一产品类型没有其他Org订阅。
• 验证通过后，Tenant再触发Organization的AddSubscription(productType)方法——这一步是单独的事务，Org自己验证内部不变量（自己有没有该产品的订阅）并完成修改。

为什么可行？ 因为Tenant的验证是前置检查，后续Org的修改是单聚合事务，同时你可以在数据库层面加一个(tenant_id, product_type)的唯一约束做兜底，彻底避免并发场景下的违规操作。

如果业务上必须保持Tenant和Organization为独立聚合，那用领域事件实现最终一致性是个不错的选择：

• 当Organization要添加订阅时，先在自身事务内验证内部不变量，然后把订阅标记为「待验证」状态，同时发布OrganizationSubscriptionRequested领域事件。
• 一个专门的事件处理器（比如Saga或者事件监听器）捕获这个事件后，查询当前Tenant下所有Org的订阅情况，验证是否违反Tenant的全局规则：
  • 验证通过：发布SubscriptionValidated事件，让Organization把订阅状态改成「有效」。
  • 验证失败：发布SubscriptionRejected事件，让Organization取消订阅，同时通知用户操作失败。
• 要注意给用户明确的反馈，比如“订阅申请已提交，正在审核”，等验证完成后再推送结果；另外要处理事件重复、丢失的问题，加个幂等键就好。

如果上面两种方案都暂时没法落地，你可以先搞一个订阅验证领域服务来做跨聚合的规则检查：

• 这个服务只做验证不修改聚合，提供CanCreateSubscription(tenantId, orgId, productType)方法：
  1. 查询目标Organization，确认它没有该产品的订阅。
  2. 查询Tenant下的所有Organization，确认没有其他Org订阅了同一产品。
• 验证通过后，再调用Organization的AddSubscription方法完成单聚合事务。
• 同样，数据库层面的(tenant_id, product_type)唯一约束不能少——毕竟并发场景下，前置验证和实际修改之间可能出现“时间差”，数据库约束是最后一道防线。

• 别碰分布式事务：跨聚合的分布式事务会带来性能和复杂度的灾难，DDD更推荐用前置验证+最终一致性的方式解决，而不是强一致性的分布式事务。
• 聚合内的轻量索引很重要：Tenant聚合里不用存完整的Organization数据，只需要维护一个「产品类型-Org ID」的映射就能快速完成验证，避免频繁查询其他聚合。

内容的提问来源于stack exchange，提问作者Normand Bedard