摘自
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，主要做的工作就是数据转换
将其他领域的实体转换成当前限界上下文可以处理的实体，在不同上下文中做了一层隔离，这样当其他限界上下文业务实体有改动的时候，可以将对本限界上下文的影响降到最小。
