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

行業內不同的組織和個人從不同的視角對 “什麼是架構” 進行了闡述。

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 architecture is the important stuff ! Whatever it is ! --Ralph Johnson

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

• 結構：應用系統所選擇的架構風格，比如微服務架構、單體架構還是SOA等
• 架構屬性：系統的非功能性屬性，比如效能、可用性、可維護性等
  架構決策：系統設計過程中重要的架構決策
  設計原則：設計過程中的指導性原則

  

  
  
  結構
  

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

架構屬性

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

架構決策

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

• 直接影響高優先順序的架構屬性

• 修改對外介面：對外提供的介面修改往往需要進行充分影響分析

• 引入或者移除依賴：依賴的加入和移除往往標示著元件能力的引進和廢棄

• 改變系統的通用結構：工程結構是應用架構的重要維度之一

• 迫使研發人員改變開發方式

• 接受戰略性技術債：重構影響較大的技術債往往對現有系統會有較大影響

設計原則

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

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

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

• IEEE定義更加結構化和規範化
• Martin Fowler的定義側重架構決策的重要性
• Ralph Johnson 則更加泛化，突出 “重要” 這一核心因子

• Neil Ford則更具象化

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

系統的架構應該設計到什麼粒度？

"架構設計" 太過詳細，涵蓋了實現的 “細枝末節”，自己除了CRUD沒有發揮的空間

"架構設計" 太過宏觀，基於設計方案根本無法指導開發，自己還得重新設計

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

架構師把架構設計當作詳細的技術方案設計，牢牢把控系統實現的所有細節，產出大量的設計文件，然後交由核心開發人員做程式碼實現的執行工作。

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

• 壓縮了團隊核心開發人員的設計發揮空間，不利於其技術水平及認知的提升
• 作為架構師你真的能將所有的細節都Cover住嗎？即使耗費巨大精力完成了 “完備” 的設計，來自一線開發所面臨的各種場景是否能夠提前預知和捕獲？
• 如果需求迭代持續如此，作為核心開發人員多半會有“怨言”

• 作為團隊的架構師精力有限，持續的細節輸出會耗費巨大精力，而無法關注更加宏觀的層面

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

• 架構設計與設計（實現相關）的邊界或粒度問題

• 團隊架構師與開發人員間的職責邊界

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

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

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

• 架構是系統中重要的東西！無論它是什麼（之所以重要，是因為改變的成本高）

• 架構設計涵蓋系統中重要的架構決策

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

• 應用架構風格的選擇
• 子系統間資訊通訊的方式
• 工程採取的分層以及層間約束
• 工程應該遵循的開發規範
• 工程引入的三方類庫，或者三方框架
• 高優先順序的架構屬性：比如某次需求建設非常關注系統的效能，或者擴充套件性等架構屬性

• 其它 "重要的東西"

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

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

• 架構設計資訊要高效的同步至開發人員
• 實現過程中的變更同樣也要回向反饋至架構，以便對架構設計進行調整
  

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

如果上下文非常關注系統的擴充套件性，該架構屬性是高優先順序的架構屬性，那麼，核心模組的策略模式的應用可以看作是架構設計的範疇。而如果上下文中擴充套件性不是關注的高優先順序的架構屬性，相比之下更關注效能，那麼，這種程式碼級的設計模式選擇應該屬於架構設計的範疇之外了，而需要劃分到實現設計層面，交由核心開發自主決定。

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

• 架構風格是系統設計的頂層抽象，從宏觀視角表述系統組成。更進一步，架構風格聚焦於系統的分層、模組以及互動形式。

• 架構模式聚焦於對重複出現問題提供解決方案

二者概念不同，並不存在衝突，其聯絡如下圖所示：

• 架構模式可以應用於架構風格，在同一架構風格上下文內可以應用一或多種架構模式

• 架構風格可以組合以產生新的架構風格

  

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

• 做，收益高

• 不做，成本高

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

• 識記：識別和回溯事實性知識
• 理解：理解事實的內涵
• 應用：將事實、規則、概念、思想加以應用
• 分析：將資訊分解、關聯、區分、實驗、測試
• 評估：將資訊或思想的價值進行評價
• 創造：整合不同的資訊形成新的知識體系
  

• 悟：由內向外，透過不斷積累、持續思考，由量變到質變，直至 “開悟”

• 破：自外向內，高層次或不同的思想輸入碰撞，加速認知層次的突破

  

為學日益，為道日損。損之又損，以至於無為。無為而無不為。——《道德經》