还有 ddd

回复 群友 484 DDD 其实和前三个 TDD、BDD、SDD 不在同一层级，不过既然你把它放在一起问，那就说清楚它和这个序列的关系。 DDD 是 Domain-Driven Design，领域驱动设计。它关注的对象是业务领域模型，而不是测试或规格。核心流程是：先和业务专家把领域里的概念、术语、边界梳理清楚，产出一套通用语言（Ubiquitous Language）和模型；再按业务边界划出限界上下文（Bounded Context）；在上下文内部，让代码里的类名、方法名、模块划分都与这些概念保持一致。战略层面是限界上下文、上下文映射，战术层面是实体、值对象、聚合、聚合根、领域事件、仓储、领域服务。 它和前三个的区别在于：TDD、BDD、SDD 都是在回答“开发流程按什么顺序推进、以什么为依据”，属于方法层面；DDD 关注的则是“建模的边界画在哪里”，属于设计层面。所以 DDD 不规定你写不写测试、先写规格还是先写代码，它甚至能被 TDD 和 BDD 一起使用。 比较实际的组合关系：DDD 确定领域边界和术语，SDD 在这个边界内把需求写成精确规格，BDD 用通用语言把关键场景写成 Given/When/Then，TDD 在聚合、值对象这一层做单元测试。 要注意的常见问题：DDD 只在业务复杂度高、领域规则多的时候才会划算。业务本身很薄，比如只是 CRUD 后台，硬套聚合根、领域事件、仓储，只会得到一堆没人看得懂的间接层。另一个常见失败模式是只在技术侧做，不让业务专家参与，最后产出的是开发自己编的一套术语，跟真实业务对不上，那还不如老老实实写个数据表。