软件架构编年史：架构风格 vs. 架构模式 vs. 设计模式

覃宇，Android开发者/ThoughtWorks技术教练//译者，热衷于探究软件开发的方方面面，从端到云，从工具到实践。喜欢通过翻译来学习和分享知识，译作有《Kotlin实战》、《领域驱动设计精粹》、《Serverless架构：无服务器应用与AWS Lambda》和《云原生安全与DevOps保障》。

在上一篇文章中，我回顾了编程语言的发展史，它告诉我们：编程语言始终都在向着更好的模块化和封装性演进。

在接下来的文章里，我将记述架构风格和架构模式的演进史。所以，今天这篇文章的内容是架构风格和架构模式的定义。

和许多软件开发术语一样，这些词语也很模糊，而且不同的人有着不同的理解。MSDN 上架构风格和架构模式是一样的，但我个人更认同 George Fairbanks 和 Michael Keeling的解释和 Stack overflow 上的答案 ，以及维基百科上对两个概念的区分：关键的区别是范围。

❃ 文中提到的George Fairbanks是我翻译的《恰如其分的软件架构》作者。

还有一点需要强调的是架构风格、架构模式和设计模式并不是完全毫不相关的，它们互相补充而且都能指导我们，尽管，和往常一样，它们应该只在必要时使用。

◐ 架构风格

架构风格非常粗略地告诉我们应该如何组织代码。它的粒度比较大，说明了应用的分层和高层级的模块，这些模块和层次之间如何交互，以及它们的关系。架构风格的例子有：

• 基于组件
• 单体应用
• 分层
• 管道和过滤器
• 事件驱动
• 发布订阅
• 插件
• 客户端服务器
• 面向服务

架构风格可以有多种实现方式，拥有特定的技术环境以及特定的策略、工具和实践。

◐ 架构模式

解决反复出现的问题的常见方案就是模式。架构模式解决的就是和架构风格相关的问题。例如，“要实现一个特定层次组合的系统，我们需要哪些类，它们又如何交互”，或者“我们的面向服务架构中需要多少高层级的模块，而它们应该如何通信”，又或者“我们的客户端服务器架构要分成多少个物理层”。

架构模式对代码的影响相当大，通常会横向地(比如，如何组织同一个层次中的代码)或者纵向地(比如，请求是如何从外层进入到内层处理之后再返回的)影响整个应用。架构模式的例子有：

• 三层(tier)
• 微内核
• MVC
• MVVM

◐ 设计模式

设计模式作用的范围和架构模式不同，它们更局限一些，它们对影响的是代码中某个肯定的部分，对代码的组织影响不多。例如：

• 在运行时只知道需要实例化的类型的情况下，如何实例化一个对象(是不是用工厂类？)；
• 对象如何根据它的状态表现不同的行为(是不是用状态机或者策略模式？)。

◐ 总结

正如文章开头所言，这全部关乎于范围：

架构风格是最高抽象级别的应用设计；An Architectural Style is the application design at the highest level of abstraction;

架构模式是实现架构风格的一种方式；An Architectural Pattern is a way to implement an Architectural Style;

设计模式是解决局部问题的方法。A Design Pattern is a way to solve a localised problem.

此外，模式既可以用作指定对象的架构模式也可以用作它的设计模式，还是根据我们使用它的范围而定。

◐ 引用来源

2004 – Microsoft – Understanding Service-Oriented Architecture

2009 – Microsoft – Microsoft Application Architecture Guide

2010 – Stack Overflow – What’s the difference between Arch. Patterns and Arch. Styles?

2014 – George Fairbanks – Architecture Patterns vs. Architectural Styles

2017 – Wikipedia – List of software architecture styles and patterns

❀❀❀

☼ 屐痕处处：2021年2月27日摄于成都青羊区非遗博览园。