架构误区系列 10：不合理的分层

本期的架构误区，说的是一个比较大的课题——应用分层。可能也是比较有争议的话题，包括文中引用的范例和得出的结论，都可能对现有的一些既有的架构设计产生一定的挑战。

分层，是架构中一个永恒的话题。合理的分层，的确可以对架构的合理性带来极大的改进。同时也是对于软件质量和效率的提升的重要助力。关于软件分层的一些具体思考，可以参见《关于软件分层设计的思考》一文。

优秀的分层范例，可以罗列很多：

• Iaas、Paas 的分层，将基础设置按照分层的划分进行了固化和沉淀，推动了云计算的发展和软件行业效率的提升。大家注意我这里没有列 Saas，因为我认为 Saas 目前没有像 Iaas、Paas 这样形成成熟的分层模式，只能说实在 Paas 之上的一些固化的应用而已。

• TCP/IP 协议栈。

• Linux：内核接口层、内核功能层、内核硬件层。不同层分别解决不同的问题，很好的实现了内聚和解耦这两大软件架构的优秀品质。

• DDD 的用户接口层、应用层、领域层和基础层的分层。这个分层原则很好的将一个应用中的各种逻辑进行了了分类，并且定义了各层逻辑之间的依赖关系，很少的明确了各层的职能，划定各领域对象的边界，确定各领域对象的协作方式。SOFA基本上也是基于这个分层模式产出的优秀应用框架。

等等。

正因为分层有如此如此的魅力和很好的架构结果，所以在我们日常的架构实践中，往往会不自觉的进行一次又一次的分层。

但是，需要分多少层，怎么分层是合理的怎么分层是不合理甚至是多余的，我们有没有很深入的思考过。

这里，就举一个我认为不怎么合理的分层的案例：参数中心。

e 额

要分析这个分层是否合理，那就要明确各层之间的职责。

在原先的架构下：

• 业务应用：负责定义配置模型，负责发起配置变更。

• 灰度组件：负责保存各版本的配置，负责实施灰度推送。

新架构下，业务应用和灰度组件的职责基本没有发生变化，那参数中心的职责是什么呢：

• 参数中心：定义了一个 key-value 的宽表模型存储应用系统的配置信息，将应用系统的配置推送能力收口。

从这里看出，参数中心的职责只有定义了一个通用的数据结构，以及收口了各应用的配置推送的能力。

这个应用的加入，没有实现特定的软件分层职责，只是做了一个功能的收口。从这点上可以看出，这个应用的加入，并没有提升应用开发的效率和质量，只是一个职责的转移。

如果需要加入这一层，更合理的做法是引入低代码的方式，将业务应用的配置模型收口到这一层，同时提供基于配置模型的变更和灰度推送能力。上层的业务应用只需要轻量的集成变更和推送的入口就可以了。这种模式下，可以降低上层业务应用在配置上的开销提升效率，同时提供成熟的能力提升配置变更和推送的可靠性。

合理的软件分层，新加入的层次需要有明确的领域模型和独特的应用职责。比如 linux 中的内核硬件层，会有自己的硬件模型，抽象不同硬件的之间的交互差异对上提供统一的服务是他的职责。

明确的领域模型可以框定本层的功能范围，独特的应用职责可以对上层提供实用的能力。只有满足这两点，才能做到内聚和解耦，从而实现合理的分层架构。