领域驱动设计（DDD）——应用架构落地方案

1. 什么是DDD

与传统设计相比，总结了以下两个维度的不同点
设计思维
在传统设计思维里，会先设计表结构，然后根据表结构进行业务代码的开发，聚焦点在数据库上。而DDD是要先构建领域模型，也就是把需求拆分成独立的模块，这些模块有自己独立的功能，并与其他模块相互协作。DDD的聚焦点在领域模型上，一切都以模型为基础。
编码风格
虽然现在用的开发语言都是面向对象语言（比如Java），但是实际开发中还是采用的面向过程编程，因为现在的编程风格都是把数据模型和行为模型分开的，随着业务的不断迭代，每个类逐渐变成“上帝类”，数据模型类变成了一堆不相关的字段的组合，Service类里的逻辑也变得非常臃肿。
DDD是真正的面向对象编程，DDD的核心类结构如下：
Value Object类：或者称为Domain Primitive，是领域里的最小单元，并且是无状态的。如手机号Phone，这里的Phone不是一个字符串，而是包含了字符串phone和实现对手机号规则校验的一个类；
Entity类：有状态的实体类，每个实体类应有自己完整的属性和行为，提供完整独立的功能。实体类里的属性不同于传统的数据模型是一 堆无关联的字段的组合，实体类里的属性一定是相互关联的，就像汽车发动机的所有零部件共同组成了这一能独立运行的实体；
Domain Service：提供跨域间的操作，将多个不同的域对象装配起来，使其相互协作，形成一个完成的功能。

2. DDD架构

从架构图中可以看出，最底层不再是数据层，而是领域层。对于业务系统而言，数据库和其他第三方资源及客户端都是输入或输出，数据库只是业务产生数据后的一个存储介质，不应该介入到业务系统中。领域层是纯内存操作，不依赖任何外部系统。与外部系统的对接都是在应用层（Application Layer）处理，应用层依赖领域层。

3. 服务边界划分规则

• 从需求文档中提取业务要素（核心名词）
  要与产品经理充分沟通，了解需求的背景、意义及未来规划（前提是要有一个文档编写能力强，规划能力强的产品经理，做开发的应该都懂~）。这些核心要素是定义服务的雏形。
• 每个服务必须是一个独立运行的单元
  或者说必须要实现功能闭环。比如电商系统的订单服务、商品服务，订单服务可以实现下单功能的闭环，商品服务可以实现对商品的全生命周期管理。
• 单一原则
  服务必须是高内聚、单一职责，不能出现“你中有我，我中有你”的情况，服务之间相互交织会使系统变的异常复杂。

4. DDD设计流程

4.1 绘制领域模型图
领域模型图要描绘出业务要素之间的关系，是怎样进行协作的。这里以汽车系统为例，汽车系统是非常成熟的设计，其结构设计思想值得我们软件开发者借鉴。汽车的核心要素主要有三个：发动机、变速箱、底盘。

4.2 定义系统操作
系统操作是指前端页面对整个系统发出的各种请求，不是具体到某个服务，系统操作定义完之后再把每个操作分配到各个服务去处理。

操作	参数	返回	操作条件	操作结果
启动	发动机Id、档位	启动成功或失败	档位在额定范围内	汽车启动成功并行驶

4.3 绘制领域对象模型图
这里要说一个新的概念，聚合。聚合类似于汽车系统里的机构，机构是由一组零部件组成的可以独立运行的单元，如发动机。同样的，聚合是由一组领域对象组成的完成某个独立功能的集合体。聚合有且仅有一个根对象，外部对象只能依赖这个根对象，外部对象也只能通过这个根对象操作聚合内的对象。

4.4 绘制服务间关系图
服务关系图要能够表达出服务之间的协作关系。下图中采用的是六边形架构图绘制