关于架构设计的易变性，应该如何理解呢？

hello，大家好，我是张张，「架构精进之路」公号作者。

一、架构设计分层

通常情况下，我们的架构设计图大概率会如下图这个样子了，首先声明一点，这其实并没有什么不妥的，这也是很典型的分层设计啦~

关于各个分层的具体描述，就简单的来聊聊吧。

• Client层

这个比较简单，就不多说了。

• Business Logic

业务逻辑这层分成 Manager 和 Engine 层，Manager 负责管理流程类的易变性，Engine 负责某个活动节点本身的易变性。

什么是流程易变性呢？简单理解，就是工作流嘛。

下面的两个流程是完全相同的，只是在第二步使用的活动不一样，如果 B 和 D 干的是同一件事情，那么 B 和 D 应该被封装进同一个 Engine 中。

当然，如果 B 和 D 功能不一样，那这两个流程就不一样了，另论。

• Resource Access

这一层是资源访问层，负责一些存储资源的封装，也就是说公司内的基础设施要变化的时候，不应该影响到上层的业务，这种在 DDD 社区也有 Repo Pattern 之类的，比较好理解。

• Utilities

那些紫色的组件，一般是一些大家公用的非功能性 SDK，也比较好理解。

架构图里的模块大多是服务：

这样的分层每一次都是在解决 Who、What、How、Where 这四个问题：

从上往下，易变性是逐渐降低的，这个我们可以理解，公司里最常修改的都是上面的一些业务逻辑，底层的基础设施几年变一次就不错了。

自上而下的重用性是逐渐增加的，Manager 经常做变更、重构、完全重写，都是挺正常的。

二、架构组合设计方案

• 开放架构

任何组件都可以调用任何其它组件，而不必考虑组件所在的层。可以向上向下调用。

开发架构有很大的灵活性，不过显然会导致层与层之间互相耦合，层内的横向调用也会导致层内的相互耦合，这样的项目是没法维护的。

作者认为产生横向调用是因为架构按照功能分解的恶果之一。

• 封闭架构

封闭架构禁止层内的横向调用，并且禁止下层调用上层系统。

这样才能发挥分层的优势，将层与层之间解耦。

封闭架构只允许一层的组件调用相邻较低层中的组件，下层的组件封装更下层的逻辑。

半封闭半开放架构

基础设施的关键部分，有时互相调用是难以避免的。因为基础设施要考虑性能问题，必须要进行最大优化，而有时向下转换会导致性能问题。

但大多系统不需要半开半闭，只要封闭就可以了。

放宽一点封闭架构的规则

因为封闭架构的要求太苛刻，实际开发中确实会遇到问题，在下面这些情况下也可以酌情放宽：

• 调用 utilities
• 按业务逻辑访问资源访问，即 manager 层直接调用 resource access 层
• manager 组件调用不太相邻的引擎
• manager 组件到其它 manager 组件通过 MQ 来通信，这种情况 manager 组件不需要知道其它组件，只要发 message 就可以了
• 设计禁忌

下面这些行为都是不能允许的：

• Client 不应该在一个用例中调用多个 Manager，不应该直接调用 Engine
• Engine 不应该发布消息，不应该订阅消息队列
• Engine 与 Manager 不应该相互调用

三、总结

关于可组合架构与架构验证，一定不要根据需求设计，而是要根据易变性来设计。

设计系统时，要从需求列表中找到核心需求，在设计完成之后，先用核心用例进行架构验证。在增加新的需求时，应该不太需要变更架构，这才说明这套架构设计对了。

系统中的功能是集成的结果，而不是实现的结果。

🎉 福利：关注公众号回复关键字：重构，即可免费获取《重构：改善既有代码的设计》

·················· END ··················