软件架构模式—分层模式

Posted 2020-09-06 Ipeter

架构模式是什么

　　软件架构模式，诞生于软件开发的最大难题——需求变更。由于需求变更，导致了大量项目因为超出预算的人力、时间而归于失败。软件开发成本有限的，但需求变更似乎是无限的，这成为了一个非常难解决的问题。

软件需求变更的结果，基本上就是对于软件代码的修改。而软件代码的修改却是程序员们最头疼的事情。因为一些大型系统，其代码根本就无法完全看懂，即便能了解部分细节，在着手修改的时候，也会碰到“触一发而动全身”的问题：因为有些功能的修改，需要修改整个系统的很多部分，导致了无穷的BUG。另外一个致命的问题，就是在紧迫的时间内，对于代码的修改往往只能依赖有限的一个或几个程序员，只有他们对系统是最熟悉的。但是面临巨大的工作量，几乎无法让更多的程序员参与进来，其他人只能干瞪眼。一旦熟悉系统的程序员离职，有可能就代表了整个系统无法维护。即便是系统能分割给几个人负责，在“集成”几个部分的代码的时候，其调试和除错的工作，又常常是旷日持久的，因为那些从来没协作过的代码，隐藏着大量的误解和不兼容问题。——这一切的根源，其实只是一个最简单的事实，就是系统中对于“代码耦合”的结构问题。糟糕的代码耦合让整个系统变得难以理解、难以修改、难以分工、难以集成。

针对代码耦合的问题，软件界进行了大量的理论研究和实践，最后发现：系统的架构设计，是改善耦合的最好方式。架构设计的本质，就是：

　　划分耦合的单位——也就是划分模块。系统应该划分成什么样的模块，代表了设计者对于系统应对的需求的基本理解。一旦能清晰的划分出模块了，其代码耦合就有了最基本的范围。而模块本身也是提示程序员理解系统的基本单位。

　　规范耦合的形式——代码耦合的形式有很多种，如直接调用、事件响应、消息队列等等，这些形式提供了代码耦合的不同特征。直接调用的代码在静态阅读的时候非常容易理解，而事件响应则提供了运行时耦合的好处。耦合的形式还有另外一层含义，就是代码耦合的规范：那些模块之间应该直接耦合，哪些不能耦合，是否应该加入中间层次等等。
　　这两个关于耦合的设计，就形成了各种架构设计。

 

在软件界多年的架构设计工作之后，人们总结出一些经验，这些经验被成为“架构模式”。架构模式包含了“名称”“适应场景”“模块定义”“模块关系”这几个部分。没有任何一种架构模式是万能的，所以每个模式都必须有“适应场景”。而模式本身的内容，就是通过“模式定义”和“模块关系”两个层面的规定来表现出来。除了模式的本身内容，为了理解某种特定的架构模式，人们还会附带上一些应用案例，好让学习者能通过实例来理解这种设计的真谛。最后，还会有些关于某种设计模式的实现手段——在面向对象的设计思想下，往往会使用一种或者多种“设计模式”来作为实现。当然只要是符合架构模式的耦合规定的，都可以成为某种架构模式的实践，但是使用软件业常见的“设计模式”，还是能比较轻松的去用代码来实现这些架构。

在软件界多年的架构设计工作之后，人们总结出一些经验，这些经验被成为“架构模式”。架构模式包含了“名称”“适应场景”“模块定义”“模块关系”这几个部分。没有任何一种架构模式是万能的，所以每个模式都必须有“适应场景”。而模式本身的内容，就是通过“模式定义”和“模块关系”两个层面的规定来表现出来。除了模式的本身内容，为了理解某种特定的架构模式，人们还会附带上一些应用案例，好让学习者能通过实例来理解这种设计的真谛。最后，还会有些关于某种设计模式的实现手段——在面向对象的设计思想下，往往会使用一种或者多种“设计模式”来作为实现。当然只要是符合架构模式的耦合规定的，都可以成为某种架构模式的实践，但是使用软件业常见的“设计模式”，还是能比较轻松的去用代码来实现这些架构。

分层模式

　　分层模式的规定非常简单而有效：

　　每个模块都必须属于某个层次，提供给“第N+1层”（上层）服务；同时委派任务给“第N-1层”的模块。

　　任何一个模块，都不得逆层次调用：属于第N层的模块，不得调用（耦合）第N+1层或以上层次的模块。

　　任何一个模块，都不得跨层调用：属于第N层的模块，不应该调用第N-2层或更下层的模块。

分层模式是架构中最基本的模式，但是也是我们开发中最被忽视的模式。我们开发中往往没有去定义代码的“层次”，仅仅以“功能”纵向划分模块，没有按实现层次横向切分。

　　门面模式、策略模式都常常用来实现分层架构。

　　上文所说的例子，后来改造成了分层模型：

　　1）重复代码减少了，功能开发更快了——一顶层开发只需要学习下层类库，就可以开始开发；近似功能模块被统一，修BUG覆盖面更好。

　　2）性能提升代码能更好的覆盖了——集中了通用实现代码，也集中了优化部分。

　　3）可以并行开发，资深人员负责底层，一般人员负责上层。

　　总结一下分层模式：

　　“模式的模式”——强大同时灵活

　　适应：集成不同类型功能 ——当我们需要把很多不同功能的代码集成起来的时候，这种模式提供了最合理的结构。能让我们的代码有足够的灵活性去应对需求变更。

　　不适应：简单业务模型——如果系统本身不复杂（或者叫做可预期的修改很少），建立各种层次，然后为了符合层次间调用的规定，会增加很多不必要的代码，陷入过度设计的泥坑。

　　方法论：以业务逻辑特征建模 ——使用分层模式，往往需要我们在大脑里对问题领域进行层次抽象，这种抽象最可信赖的原则，就是按照业务逻辑去做。比如现实业务中有一个角色，我们就建立一个角色的模块；如果我们有一个场景，就以此为名建立一个这样的模块……。以业务逻辑建立的模块，本身也会让系统更容易被理解，因为在代码里能找到和现实中一一对应的概念。

　　设计模式实现：

　　门面模式 ——我们对于每个模块或者每个层次都会设计一个“门面”来降低耦合的复杂程度。
　　策略模式——抽象层次会隐藏底层的实现细节，这就是策略模式最基本的设计，我们往往会把上层作为功能接口，下层作为可选的策略来实现。