一、架构设计分层
通常情况下，我们的架构设计图大概率会如下图这个样子了，首先声明一点，这其实并没有什么不妥的，这也是很典型的分层设计啦~
关于各个分层的具体描述，就简单的来聊聊吧。
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 不应该相互调用
三、总结
关于可组合架构与架构验证，一定不要根据需求设计，而是要根据易变性来设计。
设计系统时，要从需求列表中找到核心需求，在设计完成之后，先用核心用例进行架构验证。在增加新的需求时，应该不太需要变更架构，这才说明这套架构设计对了。
系统中的功能是集成的结果，而不是实现的结果。