架构技能（七）：软件分层

分层场景无处不在，从平时最常见的企业入手来谈。

之前读过关于企业文化的一本书，里面提到了一个常见的企业员工分层模型，见下图。

关于该员工分层模型，书中大概意思描述：一个企业的基层有责任心、中层有上进心、高层有事业心，则该企业将百年长青；不同员工处于不同的层次，员工有自己明确和清晰的职责，关注自己的职责落地，大大提高工作效率；上层是下层的战略，下层是上层的战术，上层依赖下层的输出；每一层的人都是可以被替换的，“铁打的营盘，流水的兵”，所谓地球离开谁都会正常运转；中层将高层与基层隔离，不相邻的两层工作上很难对接，所以工作中一定要找对干系人，才能更好推进。

上述员工分层模型的价值与软件分层的意义恰好不谋而合，软件分层给我们带来了什么：

• 关注点分离，职责清晰，简化了复杂度，提高了研发效率；

• 软件上层基于下层输出实现本层逻辑，任何一层都可以按需更换实现；

• 软件中不相邻的两层通过中间一层很好地进行了解耦，屏蔽了复杂度的扩散。

上述三句话，有点啰嗦，简单描述就是：

• 关注点分离，职责清晰；

• 任何一层都可按需更换实现；

• 中间层屏蔽了相邻层复杂度的扩散。

网上介绍软件分层好处的文章，琳琅满目，不计其数；今天谈软件分层，重点是聊软件应该分几层？

每次做最常见的软件三层架构时，就会问自己：为什么要分三层呢？为什么不分两层或四层呢？难道软件分两层，就不能正常运行吗？业务需求就不能实现吗？这背后到底是存在着一个什么原理或放之四海而皆准的标准呢？这个 “标准” 一直影响着软件必须这样来分层才可以。

对所有研发过的软件，分析其架构和设计规律，并对共性