一文读懂架构整洁之道

• 数据层：负责与 DB 等底层数据存储介质通信，通常包括 Mapper 和 DO 等；

? ?垂直分层

但是，仅仅做到水平分层是不够的。当业务逻辑比较复杂时，涉及的用例会非常多，这些用例之间的变更原因几乎肯定是不同的，所以还要进行垂直分层，将变更原因不一样的用例切分开。

例如，很多系统的修改操作和删除操作的变更原因和变更频率是不一样的，这时候可以考虑将修改和删除进行解耦。

不论是水平分层还是垂直分层，其核心目的都是将更新频率不同的代码给分开，放入不同的组件中。

? ?解耦方式

分层后的解耦方式有多种：

• 源码层次：通过控制源代码模块间的依赖关系进行解耦，部署时仍然一起部署，适用于项目早期刚起步时；

• 部署层次：通过控制部署单元（例如 jar 包等）之间依赖进行解耦，当系统对部署和开发方面有更高的要求时，部分组件需要独立出去形成新的部署单元；

• 服务层次：通过将组件的依赖关系降低到数据结构级别，然后通过服务进行通信来解耦，当系统足够大的时候，就需要服务层次的解耦了；

但需要注意的是，不论通过哪种解耦方式进行代码的隔离，并不意味着这样就万事大吉，拥有良好可扩展和可维护性了。这也是 Bob 在《架构整洁之道》中提到的“横跨型变更”（虽然作者是在服务的这一章提出的，但我认为也适用于其他两种解耦层次）。

请看下面的出租车调度系统的服务架构图

出租车调度系统的服务架构图

图中可以看出，Taxi UI 依赖 Taxi Finder 查找符合条件的出租车，