DDD架构设计微入门(将springmvc三层改造为ddd四层架构)

以springmvc三层架构改造为ddd四层架构为列，简单的ddd微入门。

说明： 不是什么培训行业的人，纯粹是最近刚接触到ddd项目需要快速上手，所以B站借鉴图灵学院视频简单了解下，顺手做了笔记分享出来，尊重原创不易，特贴出视频链接，有需要get。

图灵B站视频链接：https://www.bilibili.com/video/BV18y4y1V7UT?p=3

DDD(Domain-Drive Design)

推荐书籍：

1）概念硬核——读起来微吃力

2）入门推荐——相比上边简单易懂

一. 系统“老化”谁的锅？

1. 引出

1）行业问题——技术与业务耦合太深

2）微服务——拆分出的单体服务也会越来越复杂

​ DDD(目前最理想)——将mvc拆成一个个的领域，每个领域内处理自己的问题，领域之间是协作的关系，随时可以将一个个的领域组合成微服务，整个项目像搭积木，随时拆组成一个整体也能拆分成一个个体

​ DDD：出现于2003-2004，微服务2014-2015；DDD之所以火，即能解决微服务解决不了的问题。

​ Q：微服务局部业务膨胀，再拆？

2. 代码差距

1）伪代码示例

截图不是很完整，三张图连起来看

2）高内聚、低耦合角度评判此伪代码

• 可维护性差：比如账户模块表结构发生变动，但与转账业务无关，所以1从数据库读取需要修改(SQL变了)

  比如风控微服务做了大型的微服务改造之后，所以3调用风控服务也需要变，很多与转账功能不相关的业务都会影响到这段代码，造成不稳定。

• 可拓展性差： 比如1从数据库读取数据这段代码，除了此处的业务，基本上没有其他业务可复用(除非偶然巧合业务重合)

• 可测试性差： 比如测试1从数据库读取数据，负责的测试环境：数据库需要有，风控微服务、kafak部署…

  无法测试某一段代码：比如1从数据库读取数据**（这里有歧义？）**

违反原则：

• 单一职责：一个类只做自己的事情，引起这段代码的原因只能有一个？
• 开放封闭原则：对功能扩展开放，对修改封闭；比如5计算新值可能有扩展的逻辑？
• 依赖反转原则： 当模块之间有依赖关系时，依赖抽象的接口，而不能是直接的实现。

3）DDD对代码改造：业务与技术细节进行隔离

改造一：抽象数据存储层

• 贫血模型(POJO)——将所有属性都写到一个实体中，由上层脚本(比如Service、Controlller)组织一些业务，久而久之，不知道有多少服务在用此实体(不知道此实体参与了哪些业务)

  贫血失忆症： 想了解此实体参与了哪些业务，还需要到Service、Controller中搜

• 充血模型——与此实体相关的业务操作都写到此实体中，梳理业务时一目了然

改造成： DDD将方法抽象为AccountRepository这样一个组件，通过接口提供实现类封装与数据库的操作

优势： 上层业务代码需要哪些实体，往AccountRepository申请即可，至于仓库是以什么样的方式拿到对象，对业务代码无影响。

对于换数据存储框架，只要修改AccountRepository的实现逻辑即可。对业务代码无影响。

​与业务代码有关联的只有AccountRepository和Account。将数据库的变化隔离开了

改造二：抽象第三方服务(隔离风控服务)

改造成： 封装为一个接口，接口下实现类，类中封装第三方微服务的接口，同时将结果进行封装(成功0r失败)。

改造三：抽象中间层(封装kafak)

改造四：计算金额改造

**改造后：**增加接口层，把状态变化、金额变化封装到一个接口层

值对象(DDD)——参数实体化(个人理解): 防止传参时传错，找bug浪费时间,提高系统质量

Example: login(“username”,“password”)——>login(userBean)

3.改造后代码

• 代码量减少
• 清晰分明的展现了业务过程（纯粹的体现了业务逻辑）
• 接下来引起代码变化的原因只可能是业务发生变化
• 更容易单元测试：每个步骤都是一个封装号的的组件(直接测试的接口)
• 可读性更好(易于开发扩展)：接手项目需要改哪里直接改对应的模块/组件
• 技术容易更新：更换存储框架只需要考虑工厂的实现
• 更容易接入其他服务
• 更容易拆成微服务架构
  

2. 什么是DDD？

用户接口层： 隔离用户变化

应用层： 调度业务逻辑代码，其业务逻辑通过调用领域层的业务方法，自己不包含任何的实现，纯粹的反应业务

领域层： 包含项目中最核心的逻辑变化，只体现业务实现逻辑，跟任何外部组件都不打交道。

3. “DDD” VS DDD(项目实战)

• MVC架构：由表—>实体——>业务。每个服务都可以调用不同得实体查询不同得表

• DDD架构：实体往上扩展服务，往下扩展存储(具体如何存，隔离到仓库得组件中)；通过实体能划分出业务得的逻辑边界(即限界上下文)

  优点： 将单体架构与微服务架构进行了统一；随时能拆成单体架构，也能组合成微服务架构。

  对服务提供了很大的灵活性

• 微服务架构：
  

4. 微服务时代，单体架构淘汰了吗

1）架构示图

• 领域层： 稳定的业务逻辑，与外层的业务场景、底层存储无关联

• 主动适配器： 接收、封装用户请求参数

• 从/被动适配器： 负责处理数据，以不同的形式响应领域服务处理后的结果
  
  2）领域编程结构

• 主动适配器： 抽象为北向的网关，相应用户的业务请求，分两个层次，处理微服务请求(远程服务)及处理本地请求(本地服务)

• 领域层之间提供消息契约层，为领域层做保护，将领域内的对象随时转换为其他需要的对象，进一步保证领域层的稳定。？？？

• 从/被适配器： 端口、适配器属于南向的网关，对响应的形式做封装
  
  3）架构下的领域合作
  
  4）DDD下单体结构与微服务结构的统一
  

5. 中台，DDD的另一个战场