笔记来源于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 层，基础组件层，各个数据库的配置，或者其他配置类，工具类等等，数据库接口实现等
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/195909.html
