摘自
https://www.jianshu.com/p/8392c63b0136
https://www.jianshu.com/p/b6ec06d6b594
https://www.zhihu.com/question/25089273/answer/969378280
https://zhuanlan.zhihu.com/p/345679681

设计流程

统一语言: 通过在业务与代码中的技术之间采用共同的语言达成
战略建模: 根据业务需求划分出初步的领域和限界上下文，以及上下文之间的关系；
战术建模: 进一步分析每个上下文内部，识别出哪些是实体，哪些是值对象；对实体、值对象进行关联和聚合，划分出聚合的范畴和聚合根；
数据仓储设计: 为聚合根设计仓储，并思考实体或值对象的创建方式；
工程实施: 在工程中实践领域模型，并在实践中检验模型的合理性，倒推模型中不足的地方并重构。在不同上下文之间适当引入防腐层

统一语言

业务语言起源于公司的业务侧，业务侧拥有需要实现的概念
业务语言中的术语由公司的的业务侧和技术侧通过协商来定义（意味着业务侧也不能总是选到最好的命名）
目标是创造可以被业务、技术和代码自身无歧义使用的共同术语，即统一语言。
要求：代码、类、方法、属性和模块的命名必须和统一语言相匹配，必要的时候需要对代码进行重构！
在PRD文档、设计文档、代码以及团队日常交流中，如果有一套领域术语是统一无歧义的，会极大地提升沟通和工作效率；避免概念理解不一致，或者语言表达上的问题，导致沟通效率低，甚至发生误解
明确概念、形成统一语言至关重要

战略建模 - 领域划分

领域模型: 能够精确反映领域中某一知识元素的载体

无关技术，具有高度的业务抽象性；
能够精确的描述领域中的知识体系；
模型彼此之间独立，同时有关联


合作关系	Partnership	两个上下文紧密合作的关系，一荣俱荣，一损俱损
共享内核	Shared Kernel	两个上下文依赖部分共享的模型
客户方-供应方开发	Customer-Supplier Development	上下文之间有组织的上下游依赖
遵奉者	Conformist	下游上下文只能盲目依赖上游上下文
防腐层	Anticorruption Layer	一个上下文通过一些适配和转换与另一个上下文交互
开放主机服务	Open Host Service	定义一种协议来让其他上下文来对本上下文进行访问
发布语言	Published Language	通常与OHS一起使用，用于定义开放主机的协议
大泥球	Big Ball of Mud	混杂在一起的上下文关系，边界不清晰
另谋他路	SeparateWay	两个完全没有任何联系的上下文

战术建模—细化上下文

提炼出业务中的精华，合理的抽象为实体(Entity)、值对象(ValueObject)、聚合(Aggregate)
这种抽象需随着领域里的概念变化而变化
结合运用这3者让项目随业务变化而进化，是DDD的核心之一
Entity
可变；有唯一ID；封装实体自操作的行为
ValueObject
不可变；无唯一ID；用于度量和描述事物，即属性
Aggregate
实体和值对象的组合；
领域服务
领域行为
不包含实体类中对实体自己操作的行为
一切领域逻辑的对外暴露都需要通过领域服务来完成。

数据仓储设计

DDD数据转换流程

//数据库资源
import com.shrb.mobile.pay.card.repo.dao.CardDao;//数据库访问对象-银行卡
import com.shrb.mobile.pay.card.repo.dao.po.CardPO;//数据库持久化对象-银行卡
import com.shrb.mobile.pay.card.repo.dao.po.CardTransferPO;//数据库持久化对象-奖池

import com.shrb.mobile.pay.card.repo.cache.CardCacheAccessObj;//分布式缓存访问对象-银行卡缓存访问
import com.shrb.mobile.pay.card.repo.repository.CardRepository;//资源库访问对象-银行卡资源库

工程实施

通过模块将限界上下文进行区分
样例： com.公司名.归属团队.业务.上下文.*

对于模块内的组织结构，一般按照领域对象、领域服务、领域资源库、防腐层等组织方式进行定义，以对应DDD中各个概念

import com.shrb.mobile.pay.card.*;//支付卡上下文
import com.shrb.mobile.pay.card.domain.valobj.*;//领域对象-值对象
import com.shrb.mobile.pay.card.domain.entity.*;//领域对象-实体
import com.shrb.mobile.pay.card.domain.aggregate.*;//领域对象-聚合根
import com.shrb.mobile.pay.card.service.*;//领域服务
import com.shrb.mobile.pay.card.repo.*;//领域资源库（仓库），封装了获取对象的逻辑，领域对象无须和底层数据库交互，它只需要从仓库中获取对象即可
import com.shrb.mobile.pay.card.acl.*;//领域防腐层

import com.shrb.mobile.pay.riskcontrol.*;//支付交易风控上下文
...
import com.shrb.mobile.pay.route.*;//支付路由上下文
...
import com.shrb.mobile.pay.thirdparty.*;//外部三方支付上下文
...

工厂(Factories)
用来创建复杂的实体或聚合
以下场景不需要工厂：
a)构造器很简单
b)构造对象时不依赖于其他对象的创建
c)用策略模式就可以解决的

防腐层
以下场景考虑引入防腐层

需要将外部上下文中的模型翻译成本上下文理解的模型。
不同上下文之间的团队协作关系，如果是供奉者关系，建议引入防腐层，避免外部上下文变化对本上下文的侵蚀。
该访问本上下文使用广泛，为了避免改动影响范围过大。

防腐层就是一个不同限界上下文之间的Adapter，主要做的工作就是数据转换

将其他领域的实体转换成当前限界上下文可以处理的实体，在不同上下文中做了一层隔离，这样当其他限界上下文业务实体有改动的时候，可以将对本限界上下文的影响降到最小。

DDD开发实践流程