不論是開發人員還是架構師，我們都一直在跟軟體系統打交道，架構是在作業中出現最頻繁的術語之一，那么，到底什么是架構？你可能有自己的答案，也有可能沒有答案，對“架構”的理解需要我們不斷在實踐中思考、歸納、演繹，形成自己的認知，

1 到底什么是軟體架構 ？

定義 ”架構是什么“ 是件非常困難的事情，不同的組織對于軟體架構有不同的定義，每個人心中也有自身對于系統架構定義的認知，就好比我們無法百分之百表述模型而只能產出模型不同維度的視圖，對架構進行完備的定義是不可能的，

“道可道，非常道，名可名，非常名”，

行業內不同的組織和個人從不同的視角對 “什么是架構” 進行了定義或闡述，

IEEE 關于架構的定義

the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution --ANSI/IEEE

將系統架構定義為：架構是系統組織結構 + 組件及聯系（組件間以及組件和環境之間） + 原則的組合，通過圖形化的形式表述該架構定義如下圖所示，這是一個非常簡潔、概念清晰的定義，其言簡意賅的表達了架構的幾個核心要素：

大師 Martin Fowler對于架構的定義有著更加簡潔的抽象，Martin Fowler 認為軟體架構是：重要并且難以改變的決策，架構設計是關于權衡的藝術，架構設計程序中充滿了各種各樣的決策，這些決策也終將反應系統架構，

Software Architecture = Important and hard to change decisions --Martin Fowler

而Ralph Johnson則對架構有更加 “泛化” 的定義：軟體架構就是重要的東西，不論它是什么！

The software architecutre is the important stuff ! Whatever it is ! --Ralph Johnson

以上的定義從高層抽象視角對什么是架構給予了自己的回答，相比之下，Neil Ford 從架構組成元素入手，從更偏向實踐的角度對架構進行了闡述，核心思想是軟體系統的架構包括以下組合元素：

結構

結構是系統架構的重要組成部分，其從宏觀上表述了系統的結構組成，架構設計的核心任務之一是為系統選擇合適的架構風格，比如，架構師基于背景關系的權衡，可以選擇模塊化單體架構風格，也可以選擇微服務架構風格，

架構屬性

架構屬性亦稱質量屬性，或非功能屬性，通常表示系統需要具備或滿足的某種 “能力”，比如高性能、可擴展性、彈性、伸縮性、容錯性、可測驗性、可維護性等等，架構設計的目標需要關注系統需要滿足的架構屬性，架構最終要體現對架構屬性支持的相關架構決策，架構屬性眾多，系統需要關注的是這些架構屬性的子集，具體的某次特定的架構設計所需要關注的架構屬性需要依據問題域的背景關系而具體分析，同時，不同的架構屬性間可能存在沖突，這種情況同樣需要架構師的權衡和決策，

架構決策

架構決策是系統架構設計程序中對解決方案的選擇，其描述了系統必須遵循的規則，架構決策隨著權衡分析而自然存在，其是系統架構設計的重要維度之一，并不是所有的決策都是架構決策，架構決策應該關注對系統有重要影響的部分，比如對架構風格的選擇對系統存在重要影響，其改變的成本較高，理當屬于架構決策的范疇，比較典型架構決策包括但不限于：

注：架構決策建議以輕量級的檔案化形式進行記錄，參考文章 《輕量級的架構決策記錄機制》一文

設計原則

設計原則與架構決策不同，其本質區別是：設計原則是一種指導，而非強制的規則，架構決策需要遵守，設計原則提供參考性指引，

比如，設計原則可能是：在可能的情況下，跨系統間的通信盡可能使用異步訊息機制以提高性能和降低耦合，

以上對架構的定義各有特點：

我個人更傾向于Ralph Johnson 對于架構的抽象化定義，簡單卻不失對架構本質的闡述，這也是我在作業中判斷架構邊界的準則之一，

2 架構設計的邊界

如果你是團隊的架構師，你是否有以下困惑：

如果你是團隊的核心開發人員，你是否 “抱怨” 過：

很多架構師自身對架構和設計的邊界缺乏深入認知，相比于對架構邊界的縮小，更多時候會出現架構設計邊界放大的情況：

架構師把架構設計當作詳細的技術方案設計，牢牢把控系統實作的所有細節，產出大量的設計檔案，然后交由核心開發人員做代碼實作的執行作業，

這種現象會導致如下問題：

以上問題的根源是什么？不能明確架構設計的邊界！

判斷架構邊界的前提之一是：明確架構和設計的關系！

所有的架構都是設計，但設計不一定是架構！

從架構的定義看架構設計的邊界，選取兩個視角：

所以，架構設計應該涵蓋系統中重要的東西，這些 “重要的東西” 可能是：

架構設計涵蓋了系統所需的重要的架構決策，從宏觀層面對系統實作予以指引，而詳細的設計則為具體的開發實作提供指導，比如，詳細的E-R圖設計、具體的代碼級別的模式選擇、某個組件的具體實作等等，

架構不是一成不變，需要持續演進，而實作相關的設計也可能在專案進行中持續變化，因此，二者不能完全割裂，而是需要在實作程序中進行雙向反饋：

在進行架構邊界判定時要注意一個至關重要的因子：背景關系！！！以上的判斷準則必須要給定的背景關系中才有價值，

比如：實作程序中大家經常會適用一些設計模式，例如策略模式，那么，這種設計模式的選擇是屬于架構設計還是詳細的實作設計？答案就是：It depends!!! 具體情況，具體分析，

如果當前背景關系，我們非常關注系統的擴展性，該架構屬性是我們高優先級的架構屬性，那么，核心模塊的策略模式的應用可以看作是架構設計的范疇，而如果背景關系中擴展性不是我們關注的高優先級的架構屬性，相比我們更關注性能，那么，這種代碼級的設計模式選擇應該屬于架構設計的范疇之外了，而需要劃分到實作設計層面，交由核心開發自主決定，

3 架構模式（Patterns）與架構風格（Styles）

架構模式和架構風格是極容易混淆的兩個概念，很多開發人員將其理解為同一事物，而實際上二者有本質區別，

二者概念不同，并不存在沖突，其聯系如下圖所示：

比較典型的例子是CQRS：CQRS本身是一種模式，將命令和查詢的職責在不同維度進行分離，該模式我們可以在單體架構風格中使用，也可以在微服務架構風格中使用，當然也可以在SOA架構風格中使用，

4 為什么要做架構設計 ？

至于 “為什么要做架構設計” 也是一個古老且頻繁出現的問題，有太多的文章闡述為社么要架構設計：有的宏觀，有的具體，有的“務實”，有的“務虛”，我把這個問題作為一個獨立章節闡述，并不是想進行大篇幅的論述，只是想突出它的重要性，這個問題值得耗費一些精力去深入理解其背后的原因，但，在此不做展開過多說明，通過一句話來進行概括：

之所以要進行架構設計，是因為：重要 ！

5 開發人員和架構師的知識模型

作為開發人員，更加關注知識的深度，以便有足夠的知識儲備滿足作業需要，開發人員在職業生涯的早期，應該關注于自身知識儲備的增長，并保持技術深度，

作為架構師，之所以技術的廣度比深度更重要，是因為架構師的重要職責之一是進行架構決策，系統架構設計是關于權衡的藝術，在特定的問題域背景關系下，架構師需要在諸多可行的解決方案間進行權衡和決策，這也對其技術廣度提出了要求，開發人員成長為架構師，應該更加關注知識的廣度，并在幾個特定領域深耕，以便有足夠的知識支撐架構決策，

雖然開發人員和架構師在知識域的關注點上存在差異，但在認知層面都可以統一到Bloom認知層次模型，該模型將認知層次劃分為逐步遞進的六個層次：

不論是架構師還是開發人員，Bloom認知層次模型都適用，通過不斷的學習擴展自身的知識體系，在識記、理解和應用的同時，要持續的培養分析、評估和創造的能力，逐步向高層次的認知水平提升，

但需要注意的是：知識不等于認知，避免陷入知識學習的陷阱，知識是無限的，沒有人能夠以有限的精力去學習無限的知識，不論是開發人員還是架構師，又或者其他角色，不應該只將精力投入在知識邊界的擴充，而應該注重從知識到認知提升的轉變，

吾生也有涯，而知也無涯，以有涯隨無涯，殆矣！已而為知者，殆而已矣！ ----《莊子》

格物以致知，對表象不斷的歸納、演繹直至事物的本象，探尋事物背后的規律，建立更高層的認知，這種認知層次由下及上的躍升有兩種方式：

為學日益，為道日損，損之又損，以?于?為，?為??不為， --《道德經》

6 結語

對架構定義的探討實際上是一種樸素的 “格物” 的程序，每個人都應該尋找自己的答案，跳脫對架構定義探討的視野，大家的作業和學習何嘗不是如此呢 ？！大道至簡，殊途同歸，格物致知，與君共勉！

作者：倪新明

標籤：其他

上一篇：京東云開發者｜探尋軟體架構的本質，到底什么是架構？

下一篇：呼叫tableView.reloadData()時UITableViewCell邊框發生變化