领域驱动设计（一、理论学习）

断更那么久，git也没更，也没回复，期间不断有人关注，感觉关注了个寂寞，其实挺不好意思的，不过，关注我的就佛系点吧，我并没那么高产，仅仅把所认知的，认为好的整理整理。网上集成工作流flowable，基本没看到正确的，后续也会更新我的集成思路。不过这篇文章主要介绍DDD架构思想方面的。

前言：微服务拆分很难，拆不好的话，看似解耦，其实只是把耦合放在了链接的桥梁上，一旦大多数需求都要通过桥梁才能实现，必然既增加了两边的工作量也增加了复杂的桥梁成本。因此，拆分既要拆分的‘小’，也要拆分的‘专’。拆分的粒度也要根据业务场景，团队情况进行充分考虑。因此我们尝试DDD的架构思想，看能不能指导我们合理的进行微服务的架构设计。

高质量代码：当用户提出一个需求变更时，为了实现这个变更而修改软件的成本越低，软件的设计质量就越高。

开放-封闭原则

对于功能扩展是开放的，即当系统需求变更时，可以对软件功能进行扩展。

对于软件代码的修改是封闭的，即在修改软件的同时不影响原有的功能，也即在不修改原有代码的基础上实现新的功能。

单一职责原则

软件系统中每个元素只完成自己职责范围内的事，而将其他的事交给别人去做，我们只去调用。一个职责就是软件变化的一个原因。

什么是DDD?

领域驱动设计最初由Eric Evans提出（2006年的《领域驱动设计》），但是多年以来一直停留在理念阶段，真正能实现并且落地的项目和公司少之又少，而进来阿里内部其实在大力推行DDD的理念，它主要可以帮助我们解决传统单体式集中架构难以快速响应业务需求落地的问题，并且针对中台和微服务盛行的场景做出指导。DDD为我们提供的是架构设计的方法论，既面向技术也面向业务，从业务的角度来把握设计方案。

DDD的作用?

想一想业务的不断变更，如何还能把握整体的业务架构设计的清晰度？

运用DDD,当系统业务变得越来越复杂时，将我们对业务的理解绘制成领域模型来正确的指导软件开发。

业务进行解耦，微服务拆分，如何确定边界？

DDD 核心思想:通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。

统一思想：统一项目各方业务、产品、开发对问题的认知，而不是开发和产品统一，业务又和产品统一从而产生分歧。

明确分工：域模型需要明确定义来解决方方面面的问题，而针对这些问题则形成了团队分钟的理解。

反映变化：需求是不断变化的，因此我们的模型也是在不断的变化的。领域模型则可以真实的反映这些变化。

边界分离：领域模型与数据模型分离，用领域模型来界定哪些需求在什么地方实现，保持结构清晰。

DDD概念

实体

有唯一标志的核心领域对象，且这个标志在整个软件生命周期中都不会发生变化。这个概念和我们平时软件模型中和数据库打交道的Model实例比较接近，唯一不同的是DDD中这些实体会包含与该实体相关的业务逻辑，它是操作行为的载体。

值对象

依附于实体存在，通过对象属性来识别的对象，它将一些相关的实体属性打包在一起处理，形成一个新的对象。

举个栗子：比如用户实体，包含用户名、密码、年龄、地址，地址又包含省市区等属性，而将省市区这些属性打包成一个属性集合就是值对象。

聚合

实体和值对象表现的是个体的能力，而我们的业务逻辑往往很复杂，依赖个体是无法完成的，这时候就需要多个实体和值对象一起协同工作，而这个协同的组织就是聚合。聚合是数据修改和持久化的基本单元，同一个聚合内要保证事务的一致性，所以在设计的时候要保证聚合的设计拆分到最小化以保证效率和性能。

聚合根

也叫做根实体，一个特殊的实体，它是聚合的管理者，代表聚合的入口，抓住聚合根可以抓住整个聚合。

领域服务

有些领域的操作是一些动词，并不能简单的把他们归类到某个实体或者值对象中。这样的行为从领域中识别出来之后应该将它声明成一个服务，它的作用仅仅是为领域提供相应的功能。

领域事件

在特定的领域由用户动作触发，表示发生在过去的事件。比如充值成功、充值失败的事件。

四种模式

失血模型

模型中只有简单的get set方法，是对一个实体最简单的封装，其他所有的业务行为由服务类来完成。

贫血模型

在失血模型基础之上聚合了业务领域行为，领域对象的状态变化停留在内存层面，不关心数据持久化。

充血模型

在贫血模型基础上，负责数据的持久化。

胀血模型

service都不需要，所有的业务逻辑、数据存储都放到一个类中。

对于DDD来说，失血和胀血都是不合适的，失血太轻量没有聚合，胀血那是初学者才这样写代码。那么充血模型和贫血模型该怎么选择？充血模型依赖repository接口，与数据存储紧密相关，有破坏程序稳定性的风险。

建模方法

用例分析法

 用例分析法是领域建模最简单可行的方式。大致可以分为获取用例、收集实体、添加关联、添加属性、模型精化几个步骤。

1. 获取用例：提取领域规则描述

2. 收集实体：定位实体，

3. 添加关联：两个实体间用动词关联起来

4. 添加属性：获取实体属性

5. 模型精化：可选的步骤，可以用UML的泛华和组合来表达模型间的关系，同时可以做子领域的划分

四色建模法

  四色建模法源于《Java Modeling In Color With UML》，它是一种模型的分析和设计方法，通过把所有模型分为四种类型，帮助模型做到清晰、可追溯。

  简单来说，四色关注的是某个人的角色在某个地点的角色用某个东西的角色做了某件事情。

事件风暴法

事件风暴法类似头脑风暴，简单来说就是谁在何时基于什么做了什么，产生了什么，影响了什么事情。

微服务架构模型现有的选择模型包括：整洁架构、CQRS 和六边形架构、DDD 分层架构等。

每种架构模式虽然提出的时代和背景不同，但其核心理念都是为了设计出“高内聚低耦合”的架构，轻松实现架构演进。DDD 分层架构的思想使架构边界变得越来越清晰，这是DDD的优点。

（一）、整洁架构

在整洁架构里，同心圆代表应用软件的不同部分，从里到外依次是领域模型、领域服务、应用服务和最外围的容易变化的内容，比如用户界面和基础设施。

整洁架构最主要的原则是依赖原则，它定义了各层的依赖关系，越往里依赖越低，代码级别越高，越是核心能力。外圆代码依赖只能指向内圆，内圆不需要知道外圆的任何情况。

（二）、六边形架构

六边形架构的核心理念是：应用是通过端口与外部进行交互的。

也就是说，在下图的六边形架构中，红圈内的核心业务逻辑（应用程序和领域模型）与外部资源（包括 APP、Web 应用以及数据库资源等）完全隔离，仅通过适配器进行交互。它解决了业务逻辑与用户界面的代码交错问题，很好地实现了前后端分离。

六边形架构各层的依赖关系与整洁架构一样，都是由外向内依赖。

六边形架构的一个端口可能对应多个外部系统，不同的外部系统也可能会使用不同的适配器，由适配器负责协议转换。这就使得应用程序能够以一致的方式被用户、程序、自动化测试和批处理脚本使用。

（三）、DDD分层架构

从上到下依次是：用户接口层、应用层、领域层和基础层。

1. 用户接口层

2. 应用层
   用户接口层负责向用户显示信息和解释用户指令。
   这里的用户可能是：用户、程序、自动化测试和批处理脚本等等。
   
   应用层是很薄的一层，理论上不应该有业务规则或逻辑，主要面向用例和流程相关的操作。
   位于领域层之上，领域层包含多个聚合，所以它可以协调多个聚合的服务和领域对象完成服务编排和组合，协作完成业务操作。
   应用层也是微服务之间交互的通道，它可以调用其它微服务的应用服务，完成微服务之间的服务组合和编排。
   
   注意：
       在设计和开发时，不要将本该放在领域层的业务逻辑放到应用层中实现。因为庞大的应用层会使领域模型失焦，时间一长你的微服务就会演化为传统的三层架构，业务逻辑会变得混乱。
       应用服务是在应用层的，它负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装，以粗粒度的服务通过 API 网关向前端发布。
       应用服务还可以进行安全认证、权限校验、事务控制、发送或订阅领域事件等。
   
   3.领域层
     领域层的作用是实现企业核心业务逻辑，通过各种校验手段保证业务的正确性。
    领域层主要体现领域模型的业务能力，它用来表达业务概念、业务状态和业务规则。
     领域层包含聚合根、实体、值对象、领域服务等领域模型中的领域对象。
   
   注意：
       领域模型的业务逻辑主要是由实体和领域服务来实现的，其中实体会采用充血模型来实现所有与之相关的业务功能。
       实体和领域服务在实现业务逻辑上不是同级的，当领域中的某些功能，单一实体（或者值对象）不能实现时，领域服务就会出马，它可以组合聚合内的多个实体（或者值对象），实现复杂的业务逻辑。
   
   4.基础层
   
    基础层是贯穿所有层的，它的作用就是为其它各层提供通用的技术和基础服务，包括第三方工具、驱动、消息中间件、网关、文件、缓存以及数据库等。比较常见的功能还是提供数据库持久化。
    基础层包含基础服务，它采用依赖倒置设计，封装基础资源服务，实现应用层、领域层与基础层的解耦，降低外部资源变化对应用的影响。
   

    5.三层架构向 DDD 分层架构演进：

DDD 分层架构中的要素其实和三层架构类似，只是在 DDD 分层架构中，这些要素被重新归类，重新划分了层，确定了层与层之间的交互规则和职责边界。

• 三层架构向 DDD 分层架构演进，主要发生在业务逻辑层和数据访问层。
  DDD 分层架构在用户接口层引入了 DTO，给前端提供了更多的可使用数据和更高的展示灵活性。

• DDD 分层架构对三层架构的业务逻辑层进行了更清晰的划分，改善了三层架构核心业务逻辑混乱，代码改动相互影响大的情况。

• DDD 分层架构将业务逻辑层的服务拆分到了应用层和领域层。应用层快速响应前端的变化，领域层实现领域模型的能力。

• 在数据访问层和基础层之间：三层架构数据访问采用 DAO 方式；DDD 分层架构的数据库等基础资源访问，采用了仓储（Repository）设计模式，通过依赖倒置实现各层对基础资源的解耦。仓储又分为两部分：仓储接口和仓储实现。仓储接口放在领域层中，仓储实现放在基础层。原来三层架构通用的第三方工具包、驱动、Common、Utility、Config 等通用的公共的资源类统一放到了基础层。
  
  

三种模型对比

• 重点关注图中的红色线框，它们是非常重要的分界线，这三种架构里面都有，它的作用就是将核心业务逻辑与外部应用、基础资源进行隔离。

• 红色框内部主要实现核心业务逻辑，划分了应用层和领域层，来承担不同的业务逻辑。

• 领域层实现面向领域模型，实现领域模型的核心业务逻辑，属于原子模型，它需要保持领域模型和业务逻辑的稳定，对外提供稳定的细粒度的领域服务，所以它处于架构的核心位置。

• 应用层实现面向用户操作相关的用例和流程，对外提供粗粒度的 API 服务。它就像一个齿轮一样进行前台应用和领域层的适配，接收前台需求，随时做出响应和调整，尽量避免将前台需求传导到领域层。应用层作为配速齿轮则位于前台应用和领域层之间。

关注三个方面：

1.如何拆分和设计，使软件维护与发布不困难。

2.面对需求不断变化，使开发质量与交付速度不变慢。

3.如何通过领域建模确认和规划系统边界，如何抽象技术中台。

实践参考：

DDD 并没有给出标准的代码模型，不同的人可能会有不同理解。

根据 DDD 分层架构模型建立了标准的微服务代码模型，在代码模型里面，各代码对象各据其位、各司其职，共同协作完成微服务的业务逻辑。它包括用户接口层、应用层、领域层和基础层，分层架构各层的职责边界非常清晰，又能有条不紊地分层协作。

• 用户接口层：面向前端提供服务适配，面向资源层提供资源适配。这一层聚集了接口适配相关的功能。

• 应用层职责：实现服务组合和编排，适应业务流程快速变化的需求。这一层聚集了应用服务和事件相关的功能。

• 领域层：实现领域的核心业务逻辑。这一层聚集了领域模型的聚合、聚合根、实体、值对象、领域服务和事件等领域对象，以及它们组合所形成的业务能力。

• 基础层：贯穿所有层，为各层提供基础资源服务。这一层聚集了各种底层资源相关的服务和能力。
  

详细介绍：

在严格分层架构模式下，不允许服务的跨层调用，每个服务只能调用它的下一层服务。服务从下到上依次为：实体方法、领域服务和应用服务。建议采用服务逐层封装的方式，服务的封装和调用主要有以下几种方式：

1.微服务一级目录结构

微服务一级目录是按照 DDD 分层架构的分层职责来定义的。从下面这张图中，我们可以看到，在代码模型里分别为用户接口层、应用层、领域层和基础层，建立了 interfaces、application、domain 和 infrastructure 四个一级代码目录。

2.用户接口层目录结构、职能和代码形态

主要存放用户接口层与前端交互、展现数据相关的代码。前端应用通过这一层的接口，向应用服务获取展现所需的数据。这一层主要用来处理用户发送的 Restful 请求，解析用户输入的配置文件，并将数据传递给 Application 层。数据的组装、数据传输格式以及 Facade 接口等代码都会放在这一层目录里。

• Assembler：实现 DTO 与领域对象之间的相互转换和数据交换。一般来说 Assembler 与 DTO 总是一同出现。

• Dto：它是数据传输的载体，内部不存在任何业务逻辑，我们可以通过 DTO 把内部的领域对象与外界隔离。

• Facade：提供较粗粒度的调用接口，将用户请求委派给一个或多个应用服务进行处理。
  

3.应用层目录结构、职能和代码形态

主要存放应用层服务组合和编排相关的代码。应用服务向下基于微服务内的领域服务或外部微服务的应用服务完成服务的编排和组合，向上为用户接口层提供各种应用数据展现支持服务。应用服务和事件等代码会放在这一层目录里。

• Event（事件）：这层目录主要存放事件相关的代码。它包括两个子目录：publish 和 subscribe。前者主要存放事件发布相关代码，后者主要存放事件订阅相关代码（事件处理相关的核心业务逻辑在领域层实现）。为了实现事件的统一管理，建议你将微服务内所有事件的发布和订阅的处理都统一放到应用层，事件相关的核心业务逻辑实现放在领域层。通过应用层调用领域层服务，来实现完整的事件发布和订阅处理流程。

• Service（应用服务）：这层的服务是应用服务。应用服务会对多个领域服务或外部应用服务进行封装、编排和组合，对外提供粗粒度的服务。应用服务主要实现服务组合和编排，是一段独立的业务逻辑。你可以将所有应用服务放在一个应用服务类里，也可以把一个应用服务设计为一个应用服务类，以防应用服务类代码量过大。
  

应用层的领域对象分析

应用层的主要领域对象是应用服务和事件的发布以及订阅。

在事件风暴或领域故事分析时，我们往往会根据用户或系统发起的命令，来设计服务或实体方法。为了响应这个命令，我们需要分析和记录：

•   在应用层和领域层分别会发生哪些业务行为；

• 各层分别需要设计哪些服务或者方法；

• 这些方法和服务的分层以及领域类型（比如实体方法、领域服务和应用服务等），它们之间的调用和组合的依赖关系。
  
  

4.领域层目录结构、职能和代码形态

主要存放领域层核心业务逻辑相关的代码。领域层可以包含多个聚合代码包，它们共同实现领域模型的核心业务逻辑。聚合以及聚合内的实体、方法、领域服务和事件等代码会放在这一层目录里。

• Aggregate（聚合）：它是聚合软件包的根目录，可以根据实际项目的聚合名称命名，比如权限聚合。在聚合内定义聚合根、实体和值对象以及领域服务之间的关系和边界。聚合内实现高内聚的业务逻辑，它的代码可以独立拆分为微服务。以聚合为单位的代码放在一个包里的主要目的是为了业务内聚，而更大的目的是为了以后微服务之间聚合的重组。聚合之间清晰的代码边界，可以让你轻松地实现以聚合为单位的微服务重组，在微服务架构演进中有着很重要的作用。

• Entity（实体）：它存放聚合根、实体、值对象以及工厂模式（Factory）相关代码。实体类采用充血模型，同一实体相关的业务逻辑都在实体类代码中实现。跨实体的业务逻辑代码在领域服务中实现。

• Event（事件）：它存放事件实体以及与事件活动相关的业务逻辑代码。

• Service（领域服务）：它存放领域服务代码。一个领域服务是多个实体组合出来的一段业务逻辑。你可以将聚合内所有领域服务都放在一个领域服务类中，你也可以把每一个领域服务设计为一个类。如果领域服务内的业务逻辑相对复杂，建议将一个领域服务设计为一个领域服务类，避免由于所有领域服务代码都放在一个领域服务类中，而出现代码臃肿的问题。领域服务封装多个实体或方法后向上层提供应用服务调用。

• Repository（仓储）：它存放所在聚合的查询或持久化领域对象的代码，通常包括仓储接口和仓储实现方法。为了方便聚合的拆分和组合，我们设定了一个原则：一个聚合对应一个仓储。（特别说明：按照 DDD 分层架构，仓储实现本应该属于基础层代码，但为了在微服务架构演进时，保证代码拆分和重组的便利性，把聚合仓储实现的代码放到了聚合包内。）
  

领域层的领域对象分析

事件风暴结束时，领域模型聚合内一般会有：聚合、实体、命令和领域事件等领域对象。

在完成故事分析和微服务设计后，微服务的聚合内一般会有：聚合、聚合根、实体、值对象、领域事件、领域服务和仓储等领域对象。

(1).设计实体

  大多数情况下，领域模型的业务实体与微服务的数据库实体是一一对应的。
但某些领域模型的实体在微服务设计时，可能会被设计为多个数据实体，或者实体的某些属性被设计为值对象。
  在分层架构里，实体采用充血模型，在实体类内实现实体的全部业务逻辑。这些不同的实体都有自己的方法和业务行为，比如地址实体有新增和修改地址的方法，银行账号实体有新增和修改银行账号的方法。
   实体类放在领域层的 Entity 目录结构下。
(2).找出聚合根

聚合根来源于领域模型，聚合根是一种特殊的实体，它有自己的属性和方法。聚合根可以实现聚合之间的对象引用，还可以引用聚合内的所有实体。

• 在个人客户聚合里，个人客户这个实体是聚合根，它负责管理地址、电话以及银行账号的生命周期。

• 个人客户聚合根通过工厂和仓储模式，实现聚合内地址、银行账号等实体和值对象数据的初始化和持久化。

  
  

  
  

  聚合根类放在代码模型的 Entity 目录结构下。聚合根有自己的实现方法，比如生成客户编码，新增和修改客户信息等方法。
  (3).设计值对象
  
    根据需要将某些实体的某些属性或属性集设计为值对象。值对象类放在代码模型的 Entity 目录结构下。
    在个人客户聚合中，客户拥有客户证件类型，它是以枚举值的形式存在，所以将它设计为值对象。
   有些领域对象可以设计为值对象，也可以设计为实体，我们需要根据具体情况来分析：

• 如果这个领域对象在其它聚合内维护生命周期，且在它依附的实体对象中只允许整体替换，我们就可以将它设计为值对象。

• 如果这个对象是多条且需要基于它做查询统计，建议将它设计为实体。
  
  (4).设计领域事件
  
  如果领域模型中领域事件会触发下一步的业务操作，我们就需要设计领域事件。
  

• 首先确定领域事件发生在微服务内还是微服务之间。

• 然后设计事件实体对象，事件的发布和订阅机制，以及事件的处理机制。

• 判断是否需要引入事件总线或消息中间件。
  
  领域事件实体和处理类放在领域层的 Event 目录结构下。领域事件的发布和订阅类建议放在应用层的 Event 目录结构下。
  (5).设计领域服务
  
  如果一个业务动作或行为跨多个实体，我们就需要设计领域服务。
  领域服务通过对多个实体和实体方法进行组合，完成核心业务逻辑。可以认为领域服务是位于实体方法之上和应用服务之下的一层业务逻辑。
  按照严格分层架构层的依赖关系：

• 如果实体的方法需要暴露给应用层，它需要封装成领域服务后才可以被应用服务调用。

• 如果有的实体方法需要被前端应用调用，我们会将它封装成领域服务，然后再封装为应用服务。
  领域服务类放在领域层的 Service 目录结构下。