软件分层的思考
分层是大自然的杰作，或者说是造物者的设计。而软件通过分层来抽象逻辑，构成整体与部分的树形分形结构。
下图是秋天的落叶，树叶脱离枝干，散落地上，很凌乱，你很难去观察这些树叶。
再回到夏天，树叶回到了树上。树是一个整体，由树干，树枝，树叶组成。我们可以很清晰观察树枝或树梢的绿叶，甚至可以方便的去寻找嫩叶或枯叶，成千上万的树叶通过树形结构的管理，变的整体有序。
树形结构非常好的管理了复杂性，树形结构是大自然创造使用非常普遍的设计，你基本上可以在很多植物上发现树形的设计。
树形的本质是一种分层结构，树干是第一层，大的树枝是第二层。。。，树叶是末层。
2. 计算机的分层
2.1 和自然树的隐喻
计算机的软件中的逻辑就像是树叶，如果我们把程序逻辑平铺直叙为一行行代码，程序运行没有问题，就好像散落一地的树叶，但我们很难看懂或维护。可以采用树形的分层来解决。把系统拆分为子系统，模块，类，方法，形成整体上一个非常整体的树。
再次强调下设计的本质：
设计的本质并不是强化能力，更多的是限制能力。
如上图，很多人看了这个图会有疑问？程序的模块依赖是网状结构，上图是不是硬生生画成了树形结构？，这种网状说法并无不对。但设计就是我们能不能把复杂的网状结构（多向依赖），变为如上图简单的树形结构（单向依赖），当树只有一个枝干的时候，就退化为简单的上下分层。
2.2 上下分层
简单的上下分层
很多程序员应该很熟悉类似下图的分层结构，上层依赖下层，表现层依赖应用服务，应用服务依赖领域服务，领域服务依赖比如数据库DAO访问。很多企业级的JAVA开发都是使用这种简单分层，管理简单，很容易理解。
随着微服务和领域服务架构的兴起，简单分层有些不够了，需要一些更细化的方法论，后面来看看「依赖倒置」和「六边形架构」。这些架构并没有推翻简单分层，只是为了更好的服务领域逻辑，对分层做出了一些补充。从设计的角度看，随着设计的加入，限制更多了
3. 依赖倒置和六边形架构
3.1 上下分层细化
让我们介入上面的分层的每个层的细节，每个仓内其实是有接口和方法组成。上层依赖的是下层提供的接口，如下：比如我们的服务层依赖于DAO的接口，从传统观点看起来很正常。
反向观点：领域逻辑才是程序的核心资产，为什么我要依赖于数据库DAO接口呢？DAO只不过帮我实现数据存储而已。
应该领域服务层来根据自己需要，指定相关数据存储标准接口。数据库存储只不过是实现的一种方式，也可是HBase或其他技术。
按照这个思路，就会形成如下架构：
3.2 依赖倒置Dependence Inversion Principle
经过改造后，依赖关系如下：此处领域服务层来定义标准（比如数据持久化标准），DAO的接口定义不再属于DAO层，而是属于领域服务层。DAO层实现此标准，可以使用数据库，HBASE，就算通过RPC（远端服务调用）也可以。
传统分层和依赖倒置的分层的区别： 好比是店大欺客和客大欺店的区别，强的一方就可以指定标准规范。类比上图也是一样，依赖要不要倒置，取决于场景，只不过在业务逻辑是主要核心资产的时候，就会产生依赖反转，业务逻辑层会掌控标准制定权。
3.3 六边形架构
六边形架构其实就是把依赖反转用到了领域逻辑占核心的架构场景中，领域逻辑是老大，制定了各种标准，其他层只要实现这些标准，辅助实现领域逻辑的战略目标。
作者：QRYC
链接：https://juejin.cn/post/7025134887543767047