笔记来源于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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。