DDD笔记
笔记来源于b站视频
1.系统“老化”
- 需求难:程序员和产品经理沟通困难,更改需求难
- 开发难:对于上前行代码的类,更改很难,只能用if-else
- 创新难:对于之前老的技术笔试SSH想更换为SSM,由于涉及太多业务sql,难以更新
- 测试难:我们只更改了一个类的一小部分代码,想要测试这个部分功能不容易。
微服务能够防止“老化”么
虽然能拆分,但是下单服务仍然会不断膨胀,单个业务不断膨胀,仍需要重构。
代码差距
传统的业务代码:
就是依次调用service接口,完成步骤。
有什么缺点?高质量代码标准:高内聚,低耦合
- 可维护性差:比如我只是要转账,但是其中还夹杂这风控系统的评估和各种审计等和转账无关的业务,这样的话如果风控系统需要改造,那么这个转账业务也需要改动。
- 可扩展性差:比如某个业务sql,只在当前类中使用,无法复用。
- 无法测试:对于这个业务需要开启风控,开启kafka等。
违反那些代码原则?
- 单一职责:这个类不仅做转账,还做风控,评审
- 开闭原则:对扩展开放,对修改封闭。比如转账操作,我们有打折优惠,就需要改动代码,那么我们可以将转账操作提出来,封装到一个方法中。
- 依赖反转:依赖接口,而不是实现类
如何改造?
那讲讲我实习过程中的公司使用的 DDD 吧
DDD 没有固定的格式,每个人都有不同的写法,不过这时可以通过约定来规定。
一般来说,有 port(view) 层,这一层是 rpc 的接口实现层,或者是spring 的 controller 层。
application 层,这一层或许会调用多个domain 下的 service,不仅当前包的,还有其他包下的 service 都可以在这层调用。如果逻辑很简单,那么直接调用 repository 层也可以。
domain 层,这里有所谓领域模型,还有 service 业务逻辑,还有数据库层接口定义 repository。
infra 层,基础组件层,各个数据库的配置,或者其他配置类,工具类等等,数据库接口实现等