其实很多人都知道软件构架和开发过程中的核心思想就是解耦。解耦的核心就是将需要以不同的原因而修改的部分分开。
水平解耦
将用户界面，数据库，业务逻辑，服务框架等元素解耦，因为不同层次的结构所改变的原因并不一致。例如，用户界面的修改不应该导致数据库的修改，同样，数据库的修改也不应该影响用户界面。
垂直解耦
一个系统的功能之间也会因为不同的原因而修改。例如，在一个线上购物系统中，下单的功能可能会由于不同的商品而进行修改，而删除订单的功能却在大多情况的不需要被修改。于是对于下单和删除订单这两个功能，我们就可以从用户界面到业务逻辑层面垂直的解耦。
开发和部署解耦
系统中的每个模块必须时可以独立开发测试的。水平解耦可以将开发小组分为业务逻辑小组，数据库小组和界面小组。垂直解耦可以将小组分为下单小组和删除订单小组。由于每个模块是可以独立开发并测试的，这就意味着这个模块可以独立的部署。这将极大的提高整个项目的开发进度。
重复
大多数人都很害怕重复，DRY 原则告诉我们不要重复相同的代码和逻辑。 然而，很多时候重复时虚假的。当你发现两个模块中有相同的代码时，不要急着将其提取出来，每次将重复代码提取出来，都是在增加这两个模块的耦合性。如果其中一个模快由于特殊需求需要改动这部分代码时，你就必须考虑这会不会影响其他部分。
解耦的三种模式
源码层面的解耦模式
我们可以通过控制源码的依赖来将不同的模块解耦，其中一个模块的改变将不需要另一个模块的修改或者重新编译。在这个层面上，模块直接通过方法的调用进行连接。
部署层面的解耦模式
我们可以通过管理最小可部署的单位之间的依赖来解耦。例如很多支持热插拔的系统。例如VS Code Extensions。其中一个模块的更新和发布，并不会影响其他部分的正常工作。
服务层面的解耦模式
我们可以直接吧模块分割为不同的微服务，通过数据结构和API进行连接。
微服务在大多情况下解耦能力都是最强的，可是，微服务为带来很多的部署，连接和配置的代价。这些代价在开发初期是不必要的。
结论
我们可以尝试在开发初期只使用源码层面的解耦，但是保留服务层面解耦的机会。这样在后期开发中如果需要将其中一个模块变成微服务也不会花费太多精力。