DDD聚合建模咨询：跨企业集团用户唯一性校验方案探讨

你的方案可行性分析 #

你提出的「仅维护集团用户ID列表的Group特殊聚合」方案在特定业务场景下是可行的，但需要聚焦核心职责并规避潜在问题：

• 这个聚合的职责必须极度单一：只负责校验用户ID在集团内的全局唯一性，暴露addUser(userId, companyId)方法（需关联目标公司，因为用户最终要归属具体业务单元），内部校验通过后生成UserAddedToGroup事件即可，不承载其他业务逻辑。
• 需提前应对性能瓶颈：所有添加用户的请求都会经过该聚合，高并发场景下要通过乐观锁（如版本号字段）、分布式锁或分片策略处理并发冲突，避免成为系统单点。
• 明确数据边界：该聚合仅存储用户ID列表，用户的详细业务属性、归属公司关系需在Company或User聚合中维护，通过事件驱动同步状态——比如UserAddedToGroup事件触发Company聚合完成用户归属绑定。

跨聚合不变量的最终一致性落地建议 #

针对跨聚合的不变量约束，最终一致性是更务实的工程选择，结合你的场景可按以下流程设计：

• 拆分核心聚合：
  • EnterpriseGroup：仅维护集团基础信息，不直接嵌套公司或用户列表。
  • Company：维护自身用户列表与用户业务属性（如角色、部门）。
  • UserUniquenessGuard：即你设想的特殊聚合，唯一职责是保障集团内用户ID的唯一性。
• 事件驱动流程：
  1. 发起添加用户请求时，先调用UserUniquenessGuard.addUser(userId, groupId)，校验通过后发布UserUniquenessVerified事件。
  2. Company聚合订阅该事件，执行bindUserToCompany(userId)操作，完成用户归属绑定后发布UserBoundToCompany事件。
  3. 若UserUniquenessGuard校验失败（如并发添加同一用户），直接返回冲突错误，终止流程。
• 补偿与容错机制：
  • 若UserUniquenessGuard校验通过后，Company绑定用户失败（如数据库异常），需触发补偿逻辑：定时重试绑定操作，或发布UserBindingFailed事件，让UserUniquenessGuard移除已记录的用户ID，避免数据不一致。
• 并发冲突处理：
  • 在UserUniquenessGuard中使用乐观锁（版本字段）处理并发，当两个请求同时添加同一用户时，仅一个能成功，另一个返回冲突异常后引导用户重试。

强一致性场景的替代方案 #

如果你的业务要求用户ID唯一性是强实时约束（不允许短暂的不一致窗口），可考虑：

• 数据库层面兜底：在存储用户ID与集团ID的关联表中添加唯一联合索引，作为最后一道防线，但需注意这会将业务规则部分泄露到数据层，需权衡架构纯度。
• 分布式事务：若技术栈支持（如XA事务），可在UserUniquenessGuard与Company的操作间开启分布式事务，但要承担分布式事务的性能开销与复杂度。

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