1.2 几个相关概念

1.1.1节阐述了什么是软件架构，我们经常说的软件领域名词还有模式、类库、框架、模块、组件、服务和平台等，它们跟架构有什么关联呢？下面会逐一阐述。

1．模式（Pattern）

模式是建筑大师Christopher Alexander于二十世纪七十年代提出的概念，关于八十年代中期由Ward Cunningham和Kent Beck将其思想引入软件领域。Christopher Alexander将模式分为三个部分：一是模式产生的上下文环境（Context）；二是动机（System of Forces），也就是预期目标或要解决的问题；三是解决方案（Solution），指平衡各动机或要解决问题的一个处理手段。他提出了一个软件领域广为接受的定义：模式是表示上下文环境、动机、解决方案三方面关系的一个规则。每个模式描述了在特定上下文环境里不断重复发生的某一类问题的解决方案。

UML中给出的解释更通俗易懂：模式是对于普遍问题的普遍解决方案。我们可以把一类问题的共性抽象出来，这样就可以用同样的处理办法去解决这些问题，从而形成模式。所以模式是一些经验的总结。从这个角度来说，软件架构作为一种软件设计过程的指导准则，也是一些经验的积累和问题的抽象，同样可以看作一种模式。更一般地，根据处理问题所在领域的粒度不同，我们可以把模式分为架构模式（Architectural Pattern）、设计模式（Design Pattern）和实现模式（Implementation Pattern）三个层次。

● 架构模式是最高层次的模式，在软件过程里描述系统的基础结构、子系统划分，确定职责和边界，以及相互作用关系。一种具体的架构模式可以包含一系列的设计模式。

● 设计模式是用来处理程序设计里具体场景下的问题的办法，比如GOF（Gang of Four，指的是Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides这四位作者）在《设计模式：可复用面向对象软件的基础（Design Patterns: Elements of Reusable Object-Oriented Software）》一书里提及的23个基本设计模式（工厂模式、单例模式、代理模式、观察者模式等）, Gregor Hohpe和Bobby Woolf在《企业集成模式：设计、构建和部署消息传递解决方案（Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions）》里提及的各种集成设计模式（通道模式、消息模式、路由模式、转换模式、端点模式等）。

● 实现模式是最低层次的具体问题的处理办法，例如编码规范、命名规则等。

2．类库（Library）

类库是一组可复用的功能或工具的集合，应用系统通过调用它们从而达到复用功能的目的。例如，Windows应用开发里的各种静态或动态链接库（DLL）文件，Java开发项目里依赖的或Maven中央库里的各种jar包（比如Apache commons-io、Httpclient, Log4j等），都是类库。

类库根据其所在的语言或平台环境的不同，可以是编译后的二进制执行码或中间码形式（DLL或jar），也可以是源代码（PHP、Node.js里的类库）。类库的调用关系一般在开发期引入目标应用的项目，运行期执行实际调用。

3．框架（Framework）

框架是基于一组类库或工具，在特定领域里根据一定规则组合成的开放性的应用骨架，比如SSM/SSH框架，更大范围来说，.NET Framework、JDK都算框架。框架具有如下特性：

（1）支撑性+扩展性：框架不解决具体的业务功能问题，我们可以在框架的基础上添加各种具体的业务功能、定制特性，从而形成具体的业务应用系统。

（2）聚合性+约束性：框架是多种技术点按照一定规则形成的聚合体。我们采用某种框架也就意味着做出了技术选型的取舍。在很多种可能的技术组合里确定了一种具体的实现方式，后续的其他工作都会从这些技术出发，也需要遵循这些规则，所以框架本身影响了研发过程里的方方面面。

在一个具体的框架之上添加一些基本或可复用的功能，这时就得到一个介于框架和应用之间的结构，一般称它为脚手架（Scaffold），可以用来快速实现类似的项目。

关于框架与架构的关系，Vasyl Boroviak在stackoverflow网站上提出过一个形象的比喻，如图1-1所示。

从这个意义上来看，框架是一些具体的事物，而架构更抽象。所以一个名叫Art的stackoverflow网友说：架构是理论，框架是实现。

4．模块（Module）

模块是业务或系统按照特定维度的一种切分，也可以看作各种功能按照某种分类聚合的一种形式。例如一个电商系统，一方面，可以从业务上划分为用户模块、商品模块、订单模块、支付模块、物流模块和售后模块等。另一方面，我们也可以说用户模块聚合了用户注册、用户验证等业务功能。这样，我们在设计和开发的过程中，就可以按照模块的维度去组织，比如每个模块新建一个源码的子项目（subproject）、打包成一个单独的jar包，也可以放到一个项目里用不同的package名称来区分等。模块一般是系统在较大粒度上的解耦切分，仅次于系统或子系统的级别。

5．组件（Component）

组件是一组可以复用的业务功能的集合，包含一些对象及其行为。组件可以直接作为业务系统的组成部分，粒度一般小于模块，也是一种功能的聚合形式，比如日志组件、权限组件等。根据组件的形式、行为和用途的不同，我们又可以延伸出一些概念。

● 构件（Composite）：具有层次组合关系的多个组件组合形成的复杂组件形式。比如Eclipse RCP里一个Window左边嵌套一个TreeView组件、右边添加一个GridView组件，这样就形成了一个Composite构件。

● 部件（Widget）：部件主要是有UI界面的构件，比如Windows 7或Mac系统自带的桌面天气小部件等。

● 插件（Plugin）：系统运行期间可以即插即用、随时停用或卸载的组件，一般有确定的生命周期，比如Google Atom编辑器的各种插件、OSGi中的bundle、Eclipse插件（本质上也是OSGi的bundle）等。

6．服务（Service）

成立于1993年的结构化信息标准促进组织（Organization for the Advancement of Structured Information Standards，简称OASIS, XML和WebService规范就是这个组织提出的）把服务定义为：

一种允许访问一个或多个功能的机制，其中访问需要使用规定的接口，并且与服务描述中指定的约束和策略一致。

服务是一组对外提供业务处理能力的功能，服务需要使用明确的接口方式（比如WebService或REST等），服务描述里应该包括约束和策略（比如参数、返回值，使用什么通信协议和数据格式等）。本章的面向服务架构（SOA）会详细阐述服务的相关内容。

7．平台（Platform）

一般来说，平台是一个领域或方向上的生态系统，是很多解决方案的集大成者，提供了很多的服务、接口、规范、标准、功能、工具等。例如J2EE平台，包含企业级应用开发里的各种基于Java语言和JVM虚拟机运行时的技术能力。

知乎社区编程领域优秀问题回答者ze ran说：

库是工具箱。

框架是一套通用的解决方案。

架构是高度抽象的需求，是系统中的不变量。

平台是所有可能做的事的集合。

事实上，服务、平台、架构这几个概念这几年已经被泛化了，什么地方都可以滥用这几个词，随便一个系统都可以说自己是大数据平台、XX业务平台、XXX服务化架构。

大概在2009年的时候，在一个SOA的技术交流群，一个程序员跟大家分享自己的项目是服务化的、SOA架构的。大家很好奇，请他详细讲解自己的系统是如何做到服务化的。这位程序员就给大家发了一个Eclipse里项目结构的截图，项目里的每一个目录或包名都是以service结尾的。他就跟大家解释说，这就是我们项目的面向服务架构，我们落地了SOA架构。大家说着同一个技术名词，理解和认识却完全不一样，这就贻笑大方了。

10年过去了，我们将在后续章节里分析这些年来架构技术的发展情况，同时可以了解自己所在研发团队和系统使用的架构处于何种阶段。