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 层，基础组件层，各个数据库的配置，或者其他配置类，工具类等等，数据库接口实现等

标签：转账,service,代码,业务,笔记,接口,DDD
来源： https://www.cnblogs.com/keboom/p/15876289.html