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都算框架?？蚣芫哂腥缦绿匦裕?/p>

（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年過去了，我們將在后續章節里分析這些年來架構技術的發展情況，同時可以了解自己所在研發團隊和系統使用的架構處于何種階段。