方法、模式、模型、框架、架构的区别

软件开发领域中，经常看到方法、模式、模型、框架、架构等名词，很容易弄混，查阅了不少资料，下面尝试来理清他们之间的异同点，仅供参考。

1. 差异

需要说明的是，表格说的“领域”一词，本身就是一个可大可小的名词，几个小的领域可能也只是一个大的领域的一个部分，所以这里也容易造成理解上的误区。

2. 说明

方法

在有目的的行动中，通过一连串有特定逻辑关系的动作来完成特定的任务。这些有特定逻辑关系的动作所形成的集合整体就称之为一种方法。

我认为，这里的动作指的是一种抽象的动作，而不是具体的动作。

涵盖范围：某个领域

抽象级别：中

示例：

敏捷。通常指的是一种软件开发方法，它指的是通过快速迭代来完成产品价值交付的一种方法。关于快速迭代的具体手段，它是没有具体指定的。

框架

框架一般指定了部分或者全部的具体行为方式，可以认为是方法或者模式的一种实现。

涵盖范围：某个领域

抽象级别：低

例子：

1. Scrum。是一种敏捷开发框架，它敏捷方法的一种实现。因为Scrum定义了一些比较具体的事件（sprint计划会议、每日站会、回顾会议等）和图表（燃尽图）；虽然Scrum也认为人们需要根据实际情况来对scrum进行裁剪，但这改变不了它就是一个可以拿来即用的软件开发框架的事实。
2. SpringMVC。是一种MVC框架，是MVC模式的一种实现；

模型

模型是由元素、关系、操作以及控制其相互作用的规则组成的概念系统。——赖斯和杜尔（Lesh & Doerr，2003）

模型提取了现实领域的一些共性特征进行进一步的抽象，一般包含了元素（表现上可以是多个阶段、也可以是不同的行为主体等）、元素之间的关系、操作、规则。

模型是客观事物的一种抽象展示，反映的是客观事物本身，并不是一种解决方案。

例子：

“学习新事物的一种好的办法是快速将它建立了一个抽象的模型。”

上面这句话表示的是一种学习方法，而“一个抽象的模型”指的则是对新事物本身的抽象。

涵盖范围：某个领域

抽象级别：高

模式

模式（Pattern）是解决某一类问题的方法论，把解决某类问题的方法总结归纳到理论高度，就是模式。它是从生产经验和生活经验中经过抽象和升华提炼出来的核心知识体系，是某个领域的一种解决方案。

每个模式都描述了一个在我们的环境中不断出现的问题，然后描述了该问题的解决方案的核心。通过这种方式，你可以无数次地使用那些已有的解决方案，无需在重复相同的工作。

相比模型来说，模式包含了更多的东西，不仅仅包含模型（事物本身），还包含了我们解决问题的一系列方法等。

涵盖范围：较大，可适应多个领域

抽象级别：比较高

架构

架构通常用于指导软件系统的设计，它是一个软件系统从整体到部分的最高层次的划分，它是一种对未来的预测后做出的决策。

找到一个知乎的回答，个人觉得有一定道理，仅供参考：架构是一个事物内部各个分部的逻辑结构，以及分部之间的连接关系。

架构的核心要素有整体、分部、结构和连接。

整体，即架构对象。用建筑术语表示，好比是某个具体的建筑物，用IT系统的视角来看，整体可以是一个系统，一类数据，一连串技术。整体是架构设计的目标对象。所有的架构设计活动都是从认识整体开始的，对整体的理解越深刻，架构设计的脉络性就越强，手法自然也就更显高明和远见。

分部，把整体按照一定的逻辑进行切割和拆解，再经过抽象和聚类形成的局部或片段。分布的划分往往很具有挑战性，既是对经验的考验，又是对未来判断的体现。

结构，即分部之间的空间结构。划分了分部之后，如何合理得组织这些分部，规定各个分部的职责范围，上下游，类似军队的排兵布阵。既有经验和阅历的成分，也有一些哲学、理念和现实的影响。

连接，即分部之间的交互范式。有了分部和结构还远远不够，我们的目的是整体，是一个运转良好的整体，而不是一堆看上去匠心独运、结构清晰但分散的片段。因此，如何让各个分部在指定的结构下有效的互动，且有规可循，是不可缺失的重要一环。

涵盖范围：很大。多个领域

抽象级别：非常高