单元测试
写单元测试,有时一个方法依赖其他很多服务 可以通过mock框架来实现 或者手动实现 比如依赖微服务UserSerevice 我们可以根据单元测试实现一个本地实现
单元测试能够保证将来修改需求或者增加需求 判断是否有影响其他逻辑 当我们增加逻辑后只需要将原来的单元测试跑一遍
解耦
如何解耦
封装抽象
封装和抽象作为两个非常通用的设计思想，可以应用在很多设计场景中，比如系统、模块、lib、组件、接口、类等等的设计。封装和抽象可以有效地隐藏实现的复杂性，隔离实现的易变性，给依赖的模块提供稳定且易用的抽象接口。比如，Unix 系统提供的 open() 文件操作函数，我们用起来非常简单，但是底层实现却非常复杂，涉及权限控制、并发控制、物理存储等等。我们通过将其封装成一个抽象的 open() 函数，能够有效控制代码复杂性的蔓延，将复杂性封装在局部代码中。除此之外，因为 open() 函数基于抽象而非具体的实现来定义，所以我们在改动 open() 函数的底层实现的时候，并不需要改动依赖它的上层代码，也符合我们前面提到的“高内聚、松耦合”代码的评判标准。
中间层
引入中间层能简化模块或类之间的依赖关系。下面这张图是引入中间层前后的依赖关系对比图。在引入数据存储中间层之前，A、B、C 三个模块都要依赖内存一级缓存、Redis 二级缓存、DB 持久化存储三个模块。在引入中间层之后，三个模块只需要依赖数据存储一个模块即可。从图上可以看出，中间层的引入明显地简化了依赖关系，让代码结构更加清晰
还有一个好处就是 比如我们一级缓存要替换成一个新的接口 那么我们所有依赖的地方都需要改，如果有中间层 我们只需要将中间层改成老的接口替换成新的接口
模块化
微服务模块化:商品服务 支付服务 库存服务 订单服务 等
lib库模块化 比如我们的框架包的划分 比如dubbo spring mvc