大白话讲明白—DDD（领域驱动设计）如何从0到落地

好文必读

入门还是先看看这几篇：

阿里技术专家详解 DDD 系列 第一讲- Domain Primitive
阿里技术专家详解DDD系列 第二讲 - 应用架构
阿里技术专家详解DDD系列 第三讲 - Repository模式

美团：领域驱动设计在互联网业务开发中的实践
github：ddd落地demo实现

思想感悟

其实DDD并不是一种新技术，而是一种比较好的业务重构的思想：所谓“领域驱动设计”名词很高大上，但是实际就是编写代码时，先编写领域服务层（domain层）。在领域层定义接口。基础设施层去实现接口，应用服务层去简单的编排接口。

1. 资源设施层（解耦）：Repository层技术可能会发生一下的演变：单库单表->redis+DB查询->分库分表->拆分微服务RPC调用这么演变，技术类型可能经由：jdbc Template->mybatis->jooq等演变。所以基础设施层不能和domain层进行强依赖，传输对象不能和某个存储介质强绑定（例如DB的po对象）。所以我们需要在domain层来定义接口，由Repository层来进行实现。这样的话，就可以实现可插拔的替换底层存储介质的能力。
2. 领域层（内聚）：比较好的开发模式，是将某个功能全部内聚为一个领域服务。由这个领域服务对外提供所有的能力，这样就实现了某个功能的内聚性。
3. 纵向抽取（开闭原则）：回到某个领域服务中，此时domain层的代码可以实现纵向抽取。使用模板方法模式抽取大量公用逻辑，子类去实现个性化逻辑。然后通过枚举类来维护各个策略子类，通过入参路由到具体的子类来完成业务逻辑。
4. 数据校验（内聚）：数据校验分为两类，一类是无状态的校验（例如NPE校验和url）可以将逻辑写在DP中（以实现充血对象）；一类是有状态的校验，必须借助其他类完成（例如校验id是否存在数据库中），可以将逻辑写在domain层；
5. 防腐层（解耦）：调用第三方接口时，为了不强依赖而破坏我们的代码，可以在中间加一层适配层，这一层的作用可以完成参数转换、结果缓存、兜底等逻辑。

其实一个项目中实现以上几点（非常好落地），就可以称为DDD了。

注意：DDD不是想出来的，而是一次次需求迭代出来的。