本文转载自微信公众号《架构改进之路》，作者的架构改进之路。转载本文请联系建筑改良之路公众号。大家好，我是张张，公众号《架构提升之路》的作者。1.架构设计层次通常情况下，我们的架构设计图很可能是下图这样的。首先，它没有任何问题。这也是一个典型的分层设计~关于每个划分层的具体描述，我们简单说一下。客户层比较简单，就不多说了。BusinessLogic的业务逻辑层分为Manager层和Engine层。Manager负责管理流程类的可变性，而Engine负责一个活动节点本身的可变性。什么是过程可变性？简单理解，就是workflow。下面两个流程完全一样，只是第二步用到的activity不同。如果B和D做同样的事情，那么B和D应该封装到同一个Engine中。当然，如果B和D的功能不同，那么这两个过程就不同了，另议。ResourceAccesslayer即资源访问层，负责对一些存储资源进行封装。也就是说，当公司的基础设施需要改变的时候，不应该影响到上层的业务。DDD社区中也有RepoPatterns。它更容易理解。Utilities紫色的组件一般是大家分享的一些没有功能的SDK，比较容易理解。架构图中的大部分模块都是服务：这种分层每次都解决了Who、What、How、Where这四个问题：从上到下，可变性逐渐降低，这个我们可以理解。修改频率最高的就是上面的一些业务逻辑，底层的基础设施每隔几年就变化一次。自上而下的可重用性逐渐增强，Manager频繁地进行更改、重构和完全重写是很正常的。2.架构组合设计方案开放架构的任何组件都可以调用任何其他组件，而不管该组件位于哪一层。可以上下调用。开发架构具有很大的灵活性，但显然会导致层与层之间的相互耦合，层内横向调用也会导致层内相互耦合。这样的项目无法维护。笔者认为横向调用是架构按功能分解的后果之一。封闭式架构封闭式架构禁止层内横向调用，也禁止下层调用上层系统。只有这样，我们才能发挥分层的优势，层层解耦。封闭架构只允许一层中的组件调用相邻的下层组件，下层组件封装下层的逻辑。半封闭和半开放架构基础设施的关键部分有时相互调用是不可避免的。因为基础架构是注重性能的，所以必须将其优化到最大，有时向下转换会导致性能问题。但大多数系统不需要半开半闭，只要是封闭的即可。放宽封闭架构的规则。因为封闭架构的要求太严格了，在实际开发中确实会遇到问题。以下情况也可以酌情放宽：根据业务逻辑调用utilities访问资源访问，即manager层直接调用资源访问层manager组件调用不太相邻的engine。管理器组件通过MQ与其他管理器组件进行通信。在这种情况下，管理器组件不需要知道其他组件，只需发送消息即可。设计禁忌不允许有以下行为：Client不允许在一个用例中调用多个Manager，不应该直接调用EngineEngine，不应该发布消息，不应该订阅消息队列。引擎和管理器不应相互调用。它专为可变性而设计。在设计系统时，需要从需求列表中找到核心需求。设计完成后，首先使用核心用例进行架构验证。当增加新的需求时，应该不需要改变架构，这说明架构设计是正确的。系统中的功能是集成的结果，而不是实现的结果。
