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

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

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

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

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

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

◐ 架构风格

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

• 基于组件

• 单体应用

• 分层

• 管道和过滤器

• 事件驱动

• 发布订阅

• 插件

• 客户端服务器

• 面向服务

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

◐ 架构模式

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

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

• 三层(tier)

• 微内核

• MVC

• MVVM

◐ 设计模式

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

• 在运行时只知道需要实例化的类型的情况下，如何实例化一个对象(是不是用工厂类？ )；
  

• 对象如何根据它的状态表现不同的行为(是不是用状态机或者策略模式？)。

◐ 总结

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