以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下单体结构与微服务结构的统一