聚合引用vs子实体：员工关联领域模型优化方案问询

核心思路：冗余必要属性+维护一致性 #

既然Evaluation和Contract仅依赖Employee的特定属性（如姓名），最直接的优化方式是在这两个聚合根中冗余存储这些高频访问的属性，同时通过领域事件或应用层逻辑保障数据一致性。

具体实现细节 #

• 冗余字段设计：在Evaluation和Contract聚合中新增employeeName字段，保留原有的employeeId引用。加载这两个聚合时，直接读取本地冗余属性，无需关联查询Employee聚合。
• 一致性维护：
  • 当Employee的姓名变更时，发布EmployeeNameUpdated领域事件，由订阅该事件的应用服务批量更新所有关联Evaluation和Contract的employeeName字段。
  • 若变更频率极低，可在查询时做兜底处理：若冗余字段为空（比如历史数据），临时查询Employee聚合补全，后续异步完成同步。

替代方案：只读视图投影 #

如果业务允许最终一致性，可通过预构建只读视图解决性能问题：

• 基于数据库视图或CQRS读模型，提前将Evaluation/Contract与Employee的必要属性做关联查询，生成专门的只读投影（如EvaluationWithEmployeeView、ContractWithEmployeeView）。
• 业务查询直接读取这些视图，写操作仍保留原聚合边界，通过事件驱动或定时任务更新视图数据。

不推荐子实体方案的原因 #

你提到的子实体方案违背了聚合设计的核心原则：Employee是独立聚合根，生命周期不受Evaluation/Contract影响，强行将其作为子实体会破坏聚合边界，后续业务扩展（比如Employee关联其他聚合）时会引发数据一致性和边界混乱问题。

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