DDD领域驱动设计

一. 什么是DDD

2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software （领域驱动设计），简称Evans DDD。Evans DDD是一套综合软件系统分析和设计的面向对象建模方法。
领域建模时思考问题的角度：
我们设计领域模型时不能以用户为中心作为出发点去思考问题，不能老是想着用户会对系统做什么。而应该从一个客观的角度，根据用户需求挖掘出领域内的相关事物，思考这些事物的本质关联及其变化规律作为出发点去思考问题。
领域模型是排除了人之外的客观世界模型，但是领域模型包含人所扮演的参与者角色，但是一般情况下不要让参与者角色在领域模型中占据主要位置，如果以人所扮演的参与者角色在领域模型中占据主要位置，那么各个系统的领域模型将变得没有差别，因为软件系统就是一个人机交互的系统，都是以人为主的活动记录或跟踪；比如以Eric Evans（DDD之父）在他的书中的例子中：
如果是以人为中心的话，就变成了：托运人托运货物，收货人收货物，付款人付款，等等。
如果是领域驱动设计的思想，在经过一些用户需求讨论之后，在用户需求相对明朗之后，Eric这样描述领域模型：一个Cargo（货物）涉及多个Customer（客户，如托运人、收货人、付款人），每个Customer承担不同的角色。Cargo的运送目标已指定，即Cargo有一个运送目标。由一系列满足Specification（规格）的Carrier Movement（运输动作）来完成运输目标。

二. 为什么选择DDD

1.软件系统复杂性应对
解决复杂和大规模软件的武器可以被粗略地归为三类：抽象、分治和知识。
分治 把问题空间分割为规模更小且易于处理的若干子问题。分割后的问题需要足够小，以便一个人单枪匹马就能够解决他们；其次，必须考虑如何将分割后的各个部分装配为整体。分割得越合理越易于理解，在装配成整体时，所需跟踪的细节也就越少。即更容易设计各部分的协作方式。评判什么是分治得好，即高内聚低耦合。
抽象 使用抽象能够精简问题空间，而且问题越小越容易理解。举个例子，从北京到上海出差，可以先理解为使用交通工具前往，但不需要一开始就想清楚到底是高铁还是飞机，以及乘坐他们需要注意什么。
知识 顾名思义，DDD可以认为是知识的一种。
DDD提供了这样的知识手段，让我们知道如何抽象出限界上下文以及如何去分治。

2.与微服务架构相得益彰
微服务架构众所周知，此处不做赘述。我们创建微服务时，需要创建一个高内聚、低耦合的微服务。而DDD中的限界上下文则完美匹配微服务要求，可以将该限界上下文理解为一个微服务进程。
上述是从更直观的角度来描述两者的相似处。
在系统复杂之后，我们都需要用分治来拆解问题。一般有两种方式，技术维度和业务维度。技术维度是类似MVC这样，业务维度则是指按业务领域来划分系统。
微服务架构更强调从业务维度去做分治来应对系统复杂度，而DDD也是同样的着重业务视角。
DDD的核心诉求就是将业务架构映射到系统架构上，在响应业务变化调整业务架构时，也随之变化系统架构。而微服务追求业务层面的复用，设计出来的系统架构和业务一致，在技术架构上则系统模块之间充分解耦，可以自由地选择合适的技术架构，去中心化地治理技术和数据。

三. 如何实践DDD

设计领域模型的一般步骤如下：
1.根据需求划分出初步的领域和限界上下文，以及上下文之间的关系。
2.进一步分析每个上下文内部，识别出哪些是实体，哪些是值对象。
3.对实体、值对象进行关联和聚合，划分出聚合的范畴和聚合根。
4.为聚合根设计仓储，并思考实体或值对象的创建方式。
5.在工程中实践领域模型，并在实践中检验模型的合理性，倒推模型中不足的地方并重构。

四. 战略建模

战略和战术设计是站在DDD的角度进行划分。战略设计侧重于高层次、宏观上去划分和集成限界上下文，而战术设计则关注更具体使用建模工具来细化上下文。

领域
现实世界中，领域包含了问题域和解系统。一般认为软件是对现实世界的部分模拟。在DDD中，解系统可以映射为一个个限界上下文，限界上下文就是软件对于问题域的一个特定的、有限的解决方案。

限界上下文
一个由显示边界限定的特定职责。领域模型便存在于这个边界之内。在边界内，每一个模型概念，包括它的属性和操作，都具有特殊的含义。
一个给定的业务领域会包含多个限界上下文，想与一个限界上下文沟通，则需要通过显示边界进行通信。系统