DDD聚合根互用疑问：微服务下跨聚合修改及事务锁问题

场景背景 #

• 业务包含User、Friendship、Friendship Request三类实体，以User作为聚合根
• 不想采用最终一致性方案（尤其在单个微服务内部），原因是处理FriendshipRequestSent事件时仍需锁定依赖聚合，还要额外处理错误事件

核心疑问 #

参考DDD相关实践：允许在聚合内部使用其他聚合实例作为参数，但这会要求在同一事务中修改多个聚合。那么在微服务场景下：

1. 是否可以轻易跳过“同一事务中修改多个聚合”的规则？
2. 如果要同时修改多个聚合，是不是仅需锁定整个聚合即可？

实践解答 #

关于“能不能跳过同一事务改多聚合” #

别想着轻易跳过这条规则。哪怕是在单个微服务内部，跨聚合的事务修改也会埋下不少隐患：

• 数据一致性风险：单事务里改多个聚合，一旦失败，回滚逻辑会变得异常复杂，要是出现部分回滚失败的情况，直接就会导致数据乱掉
• 并发冲突概率飙升：多个聚合同时被修改，并发场景下的冲突概率会直线上升，尤其是当多个请求同时操作关联聚合的时候
• 破坏聚合边界设计：随便跨聚合修改会直接打破聚合的封装性，这违背了DDD里聚合作为数据修改边界的核心逻辑——聚合本来就是把需要强一致修改的逻辑封装在一起，要是你总需要跨聚合强一致，大概率是聚合边界设计得不合理

关于“仅锁定整个聚合够不够” #

如果非要在同一事务里改多个聚合，全聚合锁定是必要的，但光靠它还不够：

• 为啥必须锁：锁定整个聚合能避免并发修改产生脏数据，保证事务执行期间，被修改的聚合不会被其他请求篡改
• 为啥不够：
  1. 锁粒度太粗影响性能：要是聚合本身数据量很大，全聚合锁会严重拖慢系统，直接降低并发能力
  2. 事务时长拉长放大瓶颈：单事务覆盖多个聚合会拉长事务时间，锁持有的时间越久，并发瓶颈就越明显
  3. 先反思聚合边界合理性：如果你的业务逻辑必须同时修改多个聚合，先别急着加锁，先想想是不是聚合边界设计错了——比如Friendship和Friendship Request是不是该从User聚合里拆出来，变成独立的聚合根？

针对好友关系场景的具体建议 #

回到你提到的好友关系场景：

• 调整聚合边界：可以试试把Friendship和Friendship Request设成独立的聚合根，而不是依附于User聚合。这样每个聚合的修改都能在自己的事务内完成，从根源上避免跨聚合强一致的需求
• 优化锁粒度：如果确实需要强一致（比如发送好友请求时必须同时更新发起方和接收方的状态），可以在单微服务内使用针对聚合根ID的分布式锁代替全聚合锁，缩小锁的粒度，同时保证事务内的多聚合修改是原子性的
• 重新看待最终一致性：别因为怕处理事件就抵触最终一致性。要是业务允许短暂的不一致，最终一致性方案反而能降低系统复杂度——比如发送好友请求时只修改请求聚合，通过事件异步更新双方User的好友状态，再用重试、补偿机制处理错误事件

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