领域驱动设计（DDD）中aggregate是否可保存其他聚合冗余数据维护不变量

核心结论 #

DDD完全允许聚合为了维护业务不变量保存其他聚合的冗余统计数据，这本身就是领域层处理跨聚合不变约束的常见合规实践。

两种方案的优劣势对比 #

方案1：实时count统计加锁校验 #

• 优势：初期开发成本低，无需维护冗余字段的同步逻辑，没有额外的数据一致性适配工作，适合并发极低、规则强度弱的场景。
• 劣势：
  • 性能瓶颈明显：学生数据量较大时，count查询开销极高，哪怕加了索引，高并发场景下也会成为接口性能短板
  • 业务风险高：锁机制一旦出现疏漏（比如分布式锁失效、事务隔离级别配置错误），并发入学请求很容易击穿1000人的限额，强规则下业务损失不可控
  • 领域逻辑泄露：「学校招生人数上限」本是School聚合的核心业务规则，却需要依赖外部Student聚合的查询结果实现，逻辑内聚性差

方案2：School聚合维护student_count冗余字段 #

• 优势：
  • 符合DDD设计原则：业务不变量完全收拢在School聚合的边界内校验，无需依赖外部数据，逻辑内聚可管控
  • 性能表现优异：校验直接读取School自身的属性，无需扫描Student大表，配合乐观锁（增加version字段）即可实现无大粒度锁的并发控制，吞吐能力远高于方案1
  • 可扩展性强：后续如果新增「学校学生数低于300触发缩编告警」等同类规则，直接基于已有的student_count字段实现即可，不需要额外改造查询逻辑
• 劣势：需要适配所有影响学生数量的业务场景（入学、毕业、转学、退学、数据修复等），维护冗余字段的一致性，比方案1多了部分开发量。

决策参考建议 #

• 如果「单校学生不得超过1000」是强业务不变量（比如监管要求、资源上限，超量就会产生实际业务损失），优先选方案2：额外的同步逻辑开发成本远低于业务规则被击穿的损失。可以通过领域事件降低维护成本：Student聚合在创建、删除时抛出StudentCreated、StudentDeleted领域事件，School订阅事件更新student_count，逻辑全部内聚在领域层，不会散落在业务接口中，只要做好事件幂等处理，一致性完全可以保障。
• 如果该规则只是软提示规则（超量仅触发告警、仍可正常入学），且学校入学并发量极低，可以选方案1降低初期开发成本。

补充说明 #

这里的student_count不属于不必要的冗余缓存，而是承载School业务规则的合法领域属性，只要不通过该字段反向修改Student聚合的核心数据，就不存在破坏聚合边界的问题，是DDD鼓励的设计方式。

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