DDD领域驱动设计

阳光穿透心脏的1/2处 2022-10-18 01:35 575阅读 0赞

### DDD领域驱动设计 ###

*  1. 领域驱动设计
 *   *  1.1 领域驱动概述
     *  1.2 领域驱动优点
     *  1.3 DDD解决复杂度的方式
 *  2. 领域核心知识体系
 *   *  2.1 领域知识概念
     *  2.2 领域战略战术设计
 *  3. DDD战略设计
 *   *  3.1 战略设计概述
     *  3.2 领域与子域
     *  3.3 限界上下文
     *  3.4 领域场景分析
     *  3.5 四色建模法
     *  3.6 事件风暴结果图
     *  3.7 限界上下文依赖结果图
 *  4. DDD战术设计
 *   *  4.1 战术设计概述
     *  4.2 战术模式
     *  4.3 领域建模模式
     *  4.4 对象生命周期模式
     *  4.4 其他模式
     *  4.5 总结
 *  5. DDD微服务架构模型
 *   *  5.1 基本架构
     *   *  5.1.1 DDD分层架构
         *  5.1.2 六边形理论
         *  5.1.3 CQRS架构设计
     *  5.2 DDD分层架构
     *  5.3 服务调用
     *  5.4 服务封装与组合
     *  5.5 领域架构对应关系
 *  6. DDD落地框架
 *   *  6.1.DDD实践
     *  6.2.dddbook
     *  6.3.Xtoon应用
     *  6.4.DDD Lite
     *  6.5.ruoyi\_cloud应用
     *  6.6.Cola框架
 *  7. 领域驱动案例

# 1. 领域驱动设计 #

## 1.1 领域驱动概述 ##

领域驱动设计(Domain Driven Design) 是一种从系统分析到软件建模的一套方法论。以领域为核心驱动力的设计体系。

为什么使用领域驱动设计  
1.面向对象设计，数据行为绑定，告别贫血模型。  
2.优先考虑领域模型，而不是切割数据和行为。  
3.准确传达业务规则。  
4.代码即设计。  
5.它通过边界划分将复杂业务领域简单化，帮我们设计出清晰的领域和应用边界，可以很容易地实现业务和技术统一的架构演进。

领域驱动设计，又称"软件核心复杂性应对之道"。是一套基于对象思维的业务建模设计思想，相对于 CRUD 系统有更高的灵活性，是业务人员处理复杂问题的有效手段。

## 1.2 领域驱动优点 ##

DDD最大的好处是：接触到需求第一步就是考虑领域模型，而不是将其切割成数据和行为，然后数据用数据库实现，行为使用服务实现，最后造成需求的首肢分离。DDD让你首先考虑的是业务语言，而不是数据。DDD强调业务抽象和面向对象编程，而不是过程式业务逻辑实现。重点不同导致编程世界观不同。

1.面向对象  
封装：Account的相关操作都封装在Account Entity上，提高了内聚性和可重用性。  
多态：采用策略模式的OverdraftPolicy（多态的典型应用）提高了代码的可扩展性。

2.业务语义显性化  
通用语言：“一个团队，一种语言”，将模型作为语言的支柱。确保团队在内部的所有交流中，代码中，画图，写东西，特别是讲话的时候都要使用这种语言。例如账号，转账，透支策略，这些都是非常重要的领域概念，如果这些命名都和我们日常讨论以及PRD中的描述保持一致，将会极大提升代码的可读性，减少认知成本。说到这，稍微吐槽一下我们有些工程师的英语水平，有些神翻译让一些核心领域概念变得面目全非。  
显性化：就是将隐式的业务逻辑从一推if-else里面抽取出来，用通用语言去命名、去写代码、去扩展，让其变成显示概念，比如"透支策略"这个重要的业务概念，按照事务脚本的写法，其含义完全淹没在代码逻辑中没有突显出来，看代码的人自然也是一脸懵逼，而领域模型里面将其用策略模式抽象出来，不仅提高了代码的可读性，可扩展性也好了很多。

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16]

## 1.3 DDD解决复杂度的方式 ##

首先, 典型的DDD实现了业务复杂度和技术复杂度的隔离，通过分层架构隔离了关注点，举个例子，在传统的DDD四层架构中，DDD划分出了领域层、仓储层、基础设施层、接口层；

在领域层中，存放业务逻辑的关注点，即所谓的领域行为；在应用层中，DDD暴露出了 业务用例级别 （Use Case）的服务接口，粘合业务逻辑与技术实现；在基础设施层中，DDD集中放置了支撑业务逻辑的技术实现，如：MQ消息发送、对缓存的操作等；在仓储层中，DDD放置了和领域状态相关的逻辑，打通了领域状态持久化与存储设施之间的联系。

除了划分不同分层外，DDD还提出了一个建设性的概念: “限界上下文（Bounded Context）”，通过限界上下文对业务流程分而治之，切分为不同的子系统，在每个子系统中利用DDD的分层架构/六边形架构等思想分别进行逻辑分层。通过这样的分治之后，DDD帮我们将业务复杂度隔离到了每个细分的领域内部，而且DDD本身的分治思想，也帮助我们隔离了业务需求和技术需求的关注点。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 1]这是一个典型的领域驱动设计分层架构，蓝色区域的内容与业务逻辑有关，而灰色区域的内容则与技术实现有关。这二者泾渭分明，最后汇合在应用层。  
应用层确定了业务逻辑与技术实现的边界，通过直接依赖或者依赖注入（DI，Dependency Injection）的方式将二者结合起来。充分体现了DDD能够隔离技术复杂度与业务复杂度的特点。

# 2. 领域核心知识体系 #

## 2.1 领域知识概念 ##

DDD的核心知识体系主要包括领域、子域、核心域、支撑域、通用域、限界上下文、实体、值对象、聚合、聚合根等概念。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NTgzNjU1_size_16_color_FFFFFF_t_70]

## 2.2 领域战略战术设计 ##

DDD有战略设计和战术设计之分。战略设计主要从高层"俯视"我们的软件系统，帮助我们精准地划分领域以及处理各个领域之间的关系；而战术设计则从技术实现的层面教会我们如何具体地实施DDD。

战略建模-Strategic Modeling  
限界上下文（Bounded Context）  
上下文映射图（Context Mapping）

战术建模-Tactical Modeling：  
聚合-Aggregate  
实体-Entity  
值对象-Value Objects  
资源库-Repository  
领域服务-Domain Services  
领域事件-Domain Events  
模块-Modules

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NTgzNjU1_size_16_color_FFFFFF_t_70 1]![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NTgzNjU1_size_16_color_FFFFFF_t_70 2]

# 3. DDD战略设计 #

## 3.1 战略设计概述 ##

需要指出的是，DDD绝非一套单纯的技术工具集，但是我所看到的很多程序员却的确是这么认为的，并且也是怀揣着这样的想法来使用DDD的。过于拘泥于技术上的实现将导致DDD-Lite。简单来讲，DDD-Lite将导致劣质的领域对象，因为我们忽略了DDD战略建模所带来的好处。  
DDD的战略设计主要包括领域/子域、通用语言、限界上下文和架构风格等概念。

## 3.2 领域与子域 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NTgzNjU1_size_16_color_FFFFFF_t_70 3]

## 3.3 限界上下文 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NTgzNjU1_size_16_color_FFFFFF_t_70 4]

## 3.4 领域场景分析 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NTgzNjU1_size_16_color_FFFFFF_t_70 5]

## 3.5 四色建模法 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NTgzNjU1_size_16_color_FFFFFF_t_70 6]

## 3.6 事件风暴结果图 ##

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 2]

## 3.7 限界上下文依赖结果图 ##

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 3]

# 4. DDD战术设计 #

## 4.1 战术设计概述 ##

领域驱动设计，整体包括战略和战术两部分，其中战略部分的落地需要团队合作、开发过程、流程制度等一系列支持，实施阻力相对较大。相反，战术部分，是一组面向业务的设计模式，是基于技术的一种思维方式，相对开发人员来说比较接地气，是提升个人格局比较好的切入点。

战略设计为我们提供一种高层视野来审视我们的软件系统，而战术设计则将战略设计进行具体化和细节化，它主要关注的是技术层面的实施，也是对我们程序员来得最实在的地方。

战术模式包含若干构造块模式，以便能够构建有效的领域模型。  
战术模式严重依赖于领域模型和通用语言，通过技术模式将领域模型和通用语言中的概念映射到代码实现中。随着模型的进化，代码实现也会进行重构，以更好的体现模型概念。当然，从技术重构角度也会发现一些隐含领域知识（概念），这些新的发现也会对领域模型产生影响。

战术模式和通用语言一样，都工作在特定限界上下文内，其应用边界受限界上下文的保护。

## 4.2 战术模式 ##

战术模式的作用是管理复杂性并确保领域模型中行为的清晰明确。可以使用这些模式来捕获和传递领域中的概念、关系、规则。

每个构造块模式都具有单一职责：  
1.代表领域中的概念。如实体、值对象、领域服务、领域事件、模块等；  
2.用于管理对象的生命周期。如聚合、工厂、仓库等；  
3.用于集成或跟踪。领域事件、事件溯源等。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NTgzNjU1_size_16_color_FFFFFF_t_70 7]

## 4.3 领域建模模式 ##

他们表述实现与模型间的关系，将分析模型绑定到代码实现模型。主要用于在代码中表述模型元素的模式。

1.实体  
实体表述的是领域中的概念，它是由身份而不是属性来定义的。  
实体的身份标识在生命周期中保持不变，但其属性会发生变化。实体以身份标识作为唯一凭证，沿着时间轴，记录了实体所有变更事件。  
实体的一个实例是产品，一旦产品被生成好，其唯一身份就不会发生变化，但是其描述信息、价格等可以被多次修改。

2.值对象  
值对象代表仅通过数据区分的领域元素和概念。用作模型中元素的描述，它不具有唯一标识。  
值对象不需要唯一标识，是因为它总是与另一个对象相关联，是在一个特定上下文中被解析的。通常，其生命周期会依附于它的关联对象（在这里，主要是实体对象）。  
值对象会当做不变对象来设计，在完成创建后，其状态就不能改变了。  
值对象比较好的例子就是现金，你无需关系货币的身份，只关心它的价值。如果有人用一张五美元钞票交换你的五张一美元钞票，也不会改变五美元本身。

3.领域服务

在模型中，领域服务封装了不能自然建模为值对象和实体的逻辑、流程和概念。  
它本身不具有身份和状态。它的职责是使用实体和值对象编排业务逻辑。  
领域服务的一个好例子是运输成本计算器，只要给出一组拖运货物和重量，它就能计算运输成本。

4.模块

模块主要用于组织和封装相关概念（实体、值对象、领域服务、领域事件等），这样可以简化对较大模型的理解。  
应用模块可以在领域模型中促成低耦合和搞内聚的设计。  
模块作用于单个领域，用于分解模型规模。子域用于限定领域模型适用范围（有界上下文）。

## 4.4 对象生命周期模式 ##

相对来说，之前提到的模式重点在于表达领域概念。而对象生命周期模式，有点侧重于技术，用于表示领域对象的创建和持久化。

1.聚合  
实体和值对象会相互协作，形成复杂的关联关系。我们需要在满足不变条件的前提下，将其拆分为一个个概念上的整体。通常，面对复杂的对象关系，在执行领域对象操作时，难以保证一致性和并发性。领域驱动设计由聚合模式来确保操作的一致性和事务的并发边界。大模型会通过不变性条件来划分，并组成概念化整体的实体和对象组，这个概念化整体便是聚合。

聚合根之间的关系应该通过保持对另一个聚合根 ID 的引用，而非对对象本身的引用来实现。这一原则有助于保持聚合之间的边界并避免加载不必要的对象。

不变性，是在领域模型中强制实现一致性的规则。无论何时对实体或聚合进行变更都要应用该业务规则。聚合外部的对象只能引用另一个聚合的聚合根，聚合中对象的任何变更都需要通过聚合根来完成。聚合根封装聚合数据并公开行为以对其进行修改。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 4]  
2.工厂  
如果实体或值对象的创建过程非常复杂，可以将其委托给工厂。工厂会确保在领域对象使用之前就满足所有的不变条件。  
如果领域对象很简单并且不具有特殊的不变条件，可以使用构造函数代替工厂。当从持久化存储中重建领域对象时，也可以使用工厂。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 5]  
3.仓库

仓库主要用于持久化一个聚合。将聚合作为原子单元进行处理，因此，仓库操作的最小单元就是聚合，每个聚合会对应一个仓库。  
仓库是用来检索和存储聚合的机制，是对基础框架的一种抽象。  
其他模式。![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 6]

## 4.4 其他模式 ##

1.领域事件  
领域事件表示问题空间中发生了一些业务人员关心的事情。主要用于表示领域概念。

使用领域事件主要有以下两种场景：  
1.记录模型的变更历史；  
2.作为跨聚合通信方式。

2.事件溯源

传统的仅快照式持久化的一个替代项便是事件溯源。作为实体状态存储的替代，可以存储引发该状态的系列事件。存储所有的事件会提高业务的分析能力，不仅可以得知实体当前状态，还可以得知过去任意时点的状态。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 7]

## 4.5 总结 ##

实体
            由唯一标识符定义
            标识符在整个生命周期保存不变
            基于标识符进行相等性检查
            通过方法对属性进行更新
            
    值对象
            描述问题域中的概念和特征
            不具备身份
            不变对象
            
    领域服务
            处理无法放置在实体或值对象中的领域逻辑
            无唯一标识
            无状态服务
            
    模块
            分解、组织和提高领域模型的可读性
            命名空间，降低耦合，提供模型高内聚性
            定义领域对象组间的边界
            封装比较独立的概念，是比聚合、实体等更高层次的抽象
            
    聚合
            将大对象图分解成小的领域对象群，降低技术实现的复杂性
            表示领域概念，不仅仅是领域对象集合
            确定领域一致性边界，确保领域的可靠性
            控制并发边界
            
    工厂
            将对象的使用和构造分离
            封装复杂实体和值对象的创建逻辑
            保障复杂实体和值对象的业务完整性
            
    仓库
            是聚合根在内存中的集合接口
            提供聚合根的检索和持久化需求
            将领域层与基础实施层解耦
            通常不用于报告需求
            
    领域事件
            业务人员所关心的事件，是通用语言的一部分
            记录聚合根的所有变更
            处理跨聚合的通信需求
            
    事件溯源
            使用历史事件记录替换快照存储
            提供对历史状态的查询

# 5. DDD微服务架构模型 #

## 5.1 基本架构 ##

### 5.1.1 DDD分层架构 ###

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 8]

### 5.1.2 六边形理论 ###

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 9]

### 5.1.3 CQRS架构设计 ###

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_19_color_FFFFFF_t_70_g_se_x_16]

## 5.2 DDD分层架构 ##

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 10]

1.用户接口层：面向前端用户提供服务和数据适配。这一层聚集了接口和数据适配相关的功能。
    2.应用层：实现服务组合与编排，主要适应业务流程快速变化的需求。这一层聚集了应用服务和时间订阅相关的功能。
    3.领域层：实现领域模型的核心业务逻辑。这一层聚集了领域模型的聚合、聚合根、实体、值对象、领域服务和领域事件，通过个领域对象的协同和组合形成领域模型的核心业务能力。
    4.基础设施层：它贯穿所有层，为各层提供基础资源服务。这一层聚集了各种底层资源相关的服务和能力。

## 5.3 服务调用 ##

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 11]

## 5.4 服务封装与组合 ##

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 12]

## 5.5 领域架构对应关系 ##

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 13]

# 6. DDD落地框架 #

## 6.1.DDD实践 ##

中台架构与实现 DDD和微服务  
https://gitee.com/serpmelon/leave-sample  
清晰地提供了从战略设计到战术设计以及代码落地  
个人评价：建议DDD入门必读

## 6.2.dddbook ##

阿里技术专家详解DDD系列  
https://yq.aliyun.com/articles/719251?utm\_content=g\_1000078181  
个人评价：例子精炼，项目代码结构与rdfa相似，极具参考价值

## 6.3.Xtoon应用 ##

xtoon-boot是基于领域驱动设计（DDD）并支持SaaS平台的单体应用开发脚手架.  
xtoon-boot：https://gitee.com/xtoon/xtoon-boot  
xtoon-boot提供了完整落地方案和企业级手脚架；  
后台Github地址：https://github.com/xtoon/xtoon-boot  
前端码云地址：https://gitee.com/xtoon/xtoon-boot-element  
后台码云地址：https://gitee.com/xtoon/xtoon-boot  
个人评价：重点研究如何应用

## 6.4.DDD Lite ##

DDD 领域驱动设计微服务简化版  
理论篇  
快速入门1：https://segmentfault.com/a/1190000018464713  
快速构建新闻系统：https://segmentfault.com/a/1190000018254111  
工程代码：https://gitee.com/litao851025/geekhalo-ddd  
个人评价：简洁、高效、值得重点研究  
主要问题是持久化采用的JPA，担心技术人员不熟悉

## 6.5.ruoyi\_cloud应用 ##

若依快速开发平台  
https://gitee.com/y\_project/RuoYi-Cloud  
个人评价：以该项目建立对阳光智采和rdfa的技术框架基准线

## 6.6.Cola框架 ##

cola框架是阿里大佬张建飞（Frank） 基于DDD构建的平台应用框架。“让COLA真正成为应用架构的最佳实践，帮助广大的业务技术同学，脱离酱缸代码的泥潭！”  
[https://blog.csdn.net/significantfrank/article/details/110934799][https_blog.csdn.net_significantfrank_article_details_110934799]

# 7. 领域驱动案例 #

银行转账事务脚本实现在事务脚本的实现中，关于在两个账号之间转账的领域业务逻辑都被写在了MoneyTransferService的实现里面了，而Account仅仅是getters和setters的数据结构，也就是我们说的贫血模型：

public class MoneyTransferServiceTransactionScriptImpl implements MoneyTransferService { 
        private AccountDao accountDao;
        private BankingTransactionRepository bankingTransactionRepository;
        //...
    
        @Override
        public BankingTransaction transfer(
                String fromAccountId, String toAccountId, double amount) { 
            Account fromAccount = accountDao.findById(fromAccountId);
            Account toAccount = accountDao.findById(toAccountId);
            //. . .
            double newBalance = fromAccount.getBalance() - amount;
            switch (fromAccount.getOverdraftPolicy()) { 
                case NEVER:
                    if (newBalance < 0) { 
                        throw new DebitException("Insufficient funds");
                    }
                    break;
                case ALLOWED:
                    if (newBalance < -limit) { 
                        throw new DebitException(
                                "Overdraft limit (of " + limit + ") exceeded: " + newBalance);
                    }
                    break;
            }
            fromAccount.setBalance(newBalance);
            toAccount.setBalance(toAccount.getBalance() + amount);
            BankingTransaction moneyTransferTransaction =
                    new MoneyTranferTransaction(fromAccountId, toAccountId, amount);
            bankingTransactionRepository.addTransaction(moneyTransferTransaction);
            return moneyTransferTransaction;
        }
    }

上面的代码大家看起来应该比较眼熟，因为目前大部分系统都是这么写的。其实我们是有办法做的更优雅的，这种优雅的方式就是领域建模，唯有掌握了这种优雅你才能实现从工程师向应用架构的转型。同样的业务逻辑，接下来就让我们看一下用DDD是怎么做的。银行转账领域模型实现如果用DDD的方式实现，Account实体除了账号属性之外，还包含了行为和业务逻辑，比如debit( )和credit( )方法。

// @Entity
    public class Account { 
        // @Id
        private String id;
        private double balance;
        private OverdraftPolicy overdraftPolicy;
    
        //. . .
        public double balance() { 
            return balance;
        }
    
        public void debit(double amount) { 
            this.overdraftPolicy.preDebit(this, amount);
            this.balance = this.balance - amount;
            this.overdraftPolicy.postDebit(this, amount);
        }
    
        public void credit(double amount) { 
            this.balance = this.balance + amount;
        }
    }

而且透支策略OverdraftPolicy也不仅仅是一个Enum了，而是被抽象成包含了业务规则并采用了策略模式的对象.

public interface OverdraftPolicy { 
        void preDebit(Account account, double amount);
    
        void postDebit(Account account, double amount);
    }
    
    public class NoOverdraftAllowed implements OverdraftPolicy { 
        public void preDebit(Account account, double amount) { 
            double newBalance = account.balance() - amount;
            if (newBalance < 0) { 
                throw new DebitException("Insufficient funds");
            }
        }
    
        public void postDebit(Account account, double amount) { 
        }
    }
    
    public class LimitedOverdraft implements OverdraftPolicy { 
        private double limit;
        //...
        public void preDebit(Account account, double amount) { 
            double newBalance = account.balance() - amount;
            if (newBalance < -limit) { 
                throw new DebitException(
                        "Overdraft limit (of " + limit + ") exceeded: " + newBalance);
            }
        }
    
        public void postDebit(Account account, double amount) { 
        }
    }
    
    //而Domain Service只需要调用Domain Entity对象完成业务逻辑即可。
    public class MoneyTransferServiceDomainModelImpl implements MoneyTransferService { 
        private AccountRepository accountRepository;
        private BankingTransactionRepository bankingTransactionRepository;
        //...
    
        @Override
        public BankingTransaction transfer(
                String fromAccountId, String toAccountId, double amount) { 
            Account fromAccount = accountRepository.findById(fromAccountId);
            Account toAccount = accountRepository.findById(toAccountId);
            //. . .
            fromAccount.debit(amount);
            toAccount.credit(amount);
            BankingTransaction moneyTransferTransaction =
                    new MoneyTranferTransaction(fromAccountId, toAccountId, amount);
            bankingTransactionRepository.addTransaction(moneyTransferTransaction);
            return moneyTransferTransaction;
        }
    }

通过上面的DDD重构后，原来在事务脚本中的逻辑，被分散到Domain Service，Domain Entity和OverdraftPolicy三个满足SOLID的对象中。

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20221014/f5fd40d0efcf411fa0c30c6f91fb5a7a.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20221014/90b2b5587f074b6e9e353c1c76d41b80.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NTgzNjU1_size_16_color_FFFFFF_t_70]: /images/20221014/6c9116929392422980fe412c14943e48.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NTgzNjU1_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20210604163754472.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NTgzNjU1,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NTgzNjU1_size_16_color_FFFFFF_t_70 2]: /images/20221014/cf331b98c1344003b7a8392894164ea5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NTgzNjU1_size_16_color_FFFFFF_t_70 3]: /images/20221014/98a9dd61a299431b975665f2eedb9e17.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NTgzNjU1_size_16_color_FFFFFF_t_70 4]: /images/20221014/7e9974b5c46a46f3a2f99233cfb98609.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NTgzNjU1_size_16_color_FFFFFF_t_70 5]: /images/20221014/b177bd97bfd94bc9ad5623681c103f95.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NTgzNjU1_size_16_color_FFFFFF_t_70 6]: /images/20221014/798df90edca3435a91d863429d3c5b88.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20221014/f1722becdc104af48b95a6bea47d6d96.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 3]: /images/20221014/f77e43578c9043c2bfa4c056fff5e37a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NTgzNjU1_size_16_color_FFFFFF_t_70 7]: /images/20221014/a14c3657ee0645988da6fc0c86df3864.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 4]: /images/20221014/72c9736a5fd5463b8ea7a99f43c272cb.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 5]: /images/20221014/91927b23899b4db48cc39854d78d3216.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 6]: /images/20221014/0d5c6c236dc749cdad7d644535d2e6fc.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 7]: /images/20221014/50e1bf7e2b47475aadceae2e40c4da90.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 8]: /images/20221014/821213883dad4826be5e92f525366ed1.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 9]: /images/20221014/7e5956da6d3e45438f36ceadd6b69665.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_19_color_FFFFFF_t_70_g_se_x_16]: /images/20221014/ec5bd576cc894dea915c935ec39aa99d.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 10]: /images/20221014/64c1d3c9905340a2a0295469343fbae6.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 11]: /images/20221014/faed4deaefb64026b0a793ec24658713.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 12]: /images/20221014/beaf3c70ebb5448c8f8d1022c8cf0f28.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6Z2W6IqC5YWI55Sf_size_20_color_FFFFFF_t_70_g_se_x_16 13]: /images/20221014/3b6fdcb52557415ab5f024b80c4049e2.png
[https_blog.csdn.net_significantfrank_article_details_110934799]: https://blog.csdn.net/significantfrank/article/details/110934799