DDD战术设计：新瓶装的其实是面向对象的老酒

一旦[[DDD的本质：一套处理复杂系统的等级机制|限界上下文]]被划分出来，DDD战术设计阶段引入的聚合、聚合根、仓储、实体、值对象这些新概念——聚合（一组业务逻辑上内聚的相关对象，作为一个整体处理）、聚合根（聚合内唯一的根实体，外部只能通过它来修改整个聚合）、仓储（负责持久化和检索聚合对象，提供与数据存储细节解耦的抽象层）、实体（有唯一身份标识、具备行为和状态、可参与业务规则运算的核心业务对象）、值对象（不可变、无唯一身份标识的轻量级对象，如日期范围、地址）——本质上都是面向对象的最佳实践，而非凭空创造的新东西。面向对象历史悠久，Java等语言的广泛应用早已积累了大量最佳实践，DDD这些新概念背后的思想都能在面向对象编程里找到对应：DDD的”聚合”与面向对象里”中央控制点”这条最佳实践非常相似——中央控制点强调”唯一一个正确位置”原则，每段起作用的代码只应该在一个地方能看到、也只能在一个正确位置做维护性修改，这样能降低复杂度（需要搜索的地方越少，修改越容易越安全）；”仓储”模式其实就是依赖反转原则落地的一种实现方式；”实体”和”值对象”的思想在面向对象编程中也早已被经常用到。这个洞察带来一个重要的应用提醒：在应用DDD时要避免从概念本身出发、把这些概念强行套进需求里——这是一种错误的用法；从根本上说，DDD是一种认知方式，就像面向对象是一种看待事物的认知方式一样；实际应用时应始终以业务需求为出发点，判断是否适合用DDD的某个概念——适合就用，不适合就不要勉强套用，而且DDD本身还在不断补充新的概念和理论，不能把它当成一套凝固不变的标准答案。可迁移启发：与其死记硬背”聚合根”“值对象”这些术语定义，不如直接问自己”这个业务场景里有没有需要被唯一入口控制的一组对象、有没有不该有独立身份的属性集合”——想清楚这两个业务问题，DDD的概念自然就用对了地方，而不会沦为生搬硬套的空壳。