微服务学习笔记 分层架构和六边形架构

分层架构

传统的mvc三层架构，上层依赖于下层，层与层之间有严格的界限。但是一旦业务庞大起来后，为了业务需要，就会增加新的层。新层往往有边界模糊等问题。此外，因为上层依赖于下层，当数据来源出现变更的时候（mysql专为redis或者es），数据源的切换，也会变得极为麻烦。

六边形架构

六边形架构有别于传统的分层架构，将上层对下层的依赖进行了依赖倒置，高层模块不再依赖低层模块，两者都依赖其抽象。通过适配器，将输入和输出都放到了设计的边缘部分。整个架构不再关心公开的是REST或者是GRPC，也不再关心从何处获取数据（数据库，或者ES，还是其他微服务），将核心业务逻辑和外部的关注点隔离。

核心获取数据时，只要通过抽象的接口调用定义的方法获取数据就行。

区别

个人理解上来看，两者其实差不多，当服务体量极微的时候，六边形架构其实就可以理解为传统的分层架构（此时六边形架构并没有太多种类的输入，也没有太多种类的数据来源，虽然有依赖倒置的情况，但其实可以将其整体看成为一个control层或者model层）。

六边形架构和分成架构区别在于关注点不同。六边形架构更关注与整个领域（即业务方面），将输入与输出抽象成传输层和数据源。六边形架构只关心从传输层触发业务逻辑，从数据源获取数据，而并不关心传输层到底是谁，数据源到底是谁。在需要的时候，根据依赖倒置的原则，将所需要的输入和输出注入到整个六边形架构即可。而其中的适配器是为了将六边形架构内部的数据格式转为符合各种输入输出的格式，能其够更好的使用不同传输层和数据源。

此外，正因为这种特性，六边形架构也特别适合用于测试业务代码。因为此时可以暂时将测试数据来源和测试交互剥离出去，专注于测试业务核心逻辑。

参考示例：Netflix 的六边形架构实践