在《设计服务要考虑的7个维度》中讲到设计一定要把不稳定的部分做封装。今天咱们就从这个角度重新审视一下经典的四层架构。

上面是一个经典层架构的示意图。这个架构大多数的公司和项目都在直接用，或者用其变体。

比如，某大厂上层Client客户端可能是电商、团购等，Business Logic业务逻辑层包含金融支付、收单和积分等业务，Resource Access 资源访问层是各种中间件，Resource 是数据库、块存储等。贯穿始终的是旁边的Utilities工具条，包含不限于日志、监控和告警。

坦白讲，我研究过的大厂，就没见过哪个本质上架构不是这样的。只不过根据理解的深度，层级可能会划分得更细。

下面来聊聊每一层都封装了哪些不稳定部分，简便来说，咱们称之为：易变性。

客户端层

你的系统现在或者将来可能会增加新的客户端，比如作为桌面应用、门户网站、移动APP、全息图、增强现实。

以下是在漫威电影中经常见到的全息影像技术，这个技术在上世纪70年代就已经实现了。目前在一些商店、艺术中心可以见到，将来它会成为一种更为常见的客户端技术。

与全息图一样越来越广泛应用的客户端技术还有上世纪五六十年代发明的增强现实技术，如下图：

不同的客户端应用会使用不同的技术，部署方式不同、版本不同，生命周期不同，研发团队不同。实际上，客户端层是一个典型软件系统最易变的部分。所以需要将其易变性封装到客户端层不同的模块中，一个改变不影响其他。

业务逻辑层

业务逻辑层实现的是需要的行为，可以表述为使用案例。如果你的使用案例是静态的，其实根本不需要这一层。但是我们多数见到的使用案例都是动态的。因为我们的用户在变，时间也在改变。

使用案例的变化只有两种方式：要不就是行为的序列变了，要不就是行为变了。举个例子：用户在团购网站下单，订单完成支付，本来是只有积分的：

后来增加赠送游戏道具，这就是行为变了：

由于用户对道具的增加比较关注，延时有要求，同时，随着新上线游戏的增多，其他游戏也可能和下单关联送道具。所以由串行执行序列改成并行执行：

行为的序列，我们称之为管理者；行为本身我们称之为引擎。一个管理者可能会使用多个引擎，一个引擎也可能会多个管理者之间共享。

资源访问层

资源访问层通俗来讲就是我们常说的类似CRUD这种IO操作。一个设计良好的资源访问层组件封装的都是对于资源的原子性处理。同时，资源访问层服务是可以同时被管理者和引擎之间共享的。如果一个资源访问层服务组件只有一个服务在使用，可能说明这个组件没有被设计好。

资源层

资源层包含系统依赖的物理资源，例如：数据库、文件系统、缓存或者消息队列。资源可以在系统内部或者成为独立系统，但是对你的系统来说，它只是资源。

工具条

最上面图中的垂直工具条可能是所有系统都需要的，包含安全、日志、分析、消息总线、托管和监控大屏。

本文咱们从封装易变性的角度重新审视了经典的层级架构。下次咱们从分类的角度看怎么做才能更好的封装易变性。