一.何谓解耦
分解主体成组件，各自独立，可灵活地替换
二.如何解耦
注：下面思路基于单应用，JAVA
>如何和开发环境解耦？
不要将开发环境的配置耦合在逻辑代码里
统一用类封装配置（无论配置来自配置中心还是写死的配置）
一些特殊的情况无法做到第一步，但必须得做到将配置相关的内容放在一起
这样就相当于独立隔离了一块地方当做开发环境的配置，开发环境变化了，配置统一放在一起替换起来十分方便
>如何解耦业务逻辑
分层
对业务进行分层，让业务更加独立一体，比如支付模块就单独用包包裹一层，这样便于后期更替为单独的支付中心。包结构应该基于自身考虑，合理的规划里面的结构，比如对外请求的API和对内部的其他模块的服务接口
>如何解耦数据流动的各个环节
首先简单点的数据流动环节可以分为：控制器Controller、服务Service、数据层访问层Dao
层之间是有上下关系的，上层服务调用下层服务必须通过一层对下层的抽象层调用服务，这样下层服务发生变动，不会影响上层的调用者，上下层直接的数据请求诉求通过抽象层进行，这样当数据源来自各种不同底层数据仓库的时候就变得更加容易控制。
这里有一个点：水平层怎么解耦？
什么叫水平层：同属于某一层，有相互调用。比如Service层，A调用B中的方法，B也调用A的方法，某些情况下B业务发生变动，原来A的方法已经无法支持，这个时候怎么办？
直接更改A的方法？那其他调用方如何保障正确？
增加一个新的方法？一个变更就增加一个方法，A中的方法递增将会变得恐怖，到后面又会有量的问题
业务功能正确性第一的前提下，个人认为如果方法已经被多处引用的情况，应该新增方法来适应变动。关于业务方法数量过多的情况可以用重构解决，比如将service进行更细的拆分，封装重复代码等等，但这都是需要你的业务可能复杂以及躲到一定程度了。
还有过分一点的说，可以先盲目的更加一个情况增加一个对应的方法，等到code review的时候再进行思考和重构，因为有些情况下，为了更加精简立马去想办法合并2个业务操作可能是更加不好的，情急之下可能无法考虑到一些额外情况。
采用增加方法来适应新变更，用code review和重构来做到精美，可能这是更稳健更正确的方式
