【系统架构设计百科】DDD 战术模式：聚合、实体与值对象
💡
原文中文，约17500字，阅读约需42分钟。
📝
内容提要
某团队在实施领域驱动设计时，将“订单”建模为聚合根，导致数据库锁等待增加，形成“大聚合”反模式。文章讨论了聚合、实体和值对象的设计，强调聚合边界设计原则，建议使用小聚合以提高性能和并发性。通过案例展示重构前后的聚合设计，重构后显著提升了加载速度并减少了锁冲突。
🎯
关键要点
- 某团队在实施领域驱动设计时，将整个'订单'建模为一个聚合根，导致数据库锁等待增加，形成'大聚合'反模式。
- 聚合的设计原则强调聚合边界的合理性，建议使用小聚合以提高性能和并发性。
- 重构前的订单聚合包含多个不相关的内容，导致加载时间长和锁冲突频繁。
- 重构后，聚合被拆分为多个小聚合，每个聚合只包含维护自身不变条件所需的最小数据集，显著提升了加载速度并减少了锁冲突。
❓
延伸问答
什么是聚合根，它在领域驱动设计中有什么作用？
聚合根是聚合的核心实体，外部只能通过聚合根访问聚合内部的对象，确保数据一致性和完整性。
为什么大聚合会导致数据库锁等待增加？
大聚合包含多个不相关的内容，导致在并发操作时需要锁定整个聚合，从而增加数据库锁等待时间。
如何设计小聚合以提高性能和并发性？
小聚合应只包含维护自身不变条件所需的最小数据集，避免不必要的关联，从而减少锁冲突和加载时间。
重构前后的聚合设计有什么显著变化？
重构后，聚合被拆分为多个小聚合，每个聚合只包含必要的数据，显著提升了加载速度并减少了锁冲突。
值对象和实体有什么区别？
值对象没有独立的身份标识，基于属性值相等性，而实体有身份标识，可以在生命周期内被跟踪和区分。
在领域驱动设计中，如何判断一个聚合是否过大？
可以通过加载时间长、需要联查多张表、并发冲突频繁等信号来判断聚合是否过大。
➡️
