要想準確地理解架構的定義，關鍵就在於把三組容易混淆的概念梳理清楚：
1.系統與子系統
2.模塊與組件
3.框架與架構
系統與子系統
我們先來看維基百科定義的“系統”：系統泛指由一羣有關聯的個體組成，根據某種規則運作，能完成個別元件不能單獨完成的工作的羣體。它的意思是“總體”“整體”或“聯盟”。我來提煉一下里面的關鍵內容。
1.關聯：系統是由一羣有關聯的個體組成的，沒有關聯的個體堆在一起不能成爲一個系統。例如，把一個發動機和一臺 PC 放在一起不能稱之爲一個系統，把發動機、底盤、輪胎、車架組合起來才能成爲一臺汽車。
2.規則：系統內的個體需要按照指定的規則運作，而不是單個個體各自爲政。規則規定了系統內個體分工和協作的方式。例如，汽車發動機負責產生動力，然後通過變速器和傳動軸，將動力輸出到車輪上，從而驅動汽車前進。
3.能力：系統能力與個體能力有本質的差別，系統能力不是個體能力之和，而是產生了新的能力。例如，汽車能夠載重前進，而發動機、變速器、傳動軸、車輪本身都不具備這樣的能力。
我們再來看子系統的定義：
子系統也是由一羣有關聯的個體所組成的系統，多半會是更大系統中的一部分。其實，子系統的定義和系統定義是一樣的，只是觀察的角度有差異，一個系統可能是另外一個更大系統的子系統。
模塊與組件
模塊與組件的定義並不好理解，也不能很好地進行區分。我們來看看這兩者在維基百科上的定義：軟件模塊（Module）是一套一致而互相有緊密關連的軟件組織。它分別包含了程序和數據結構兩部分。現代軟件開發往往利用模塊作爲合成的單位。模塊的接口表達了由該模塊提供的功能和調用它時所需的元素。模塊是可能分開被編寫的單位。這使它們可再用和允許人員同時協作、編寫及研究不同的模塊。軟件組件定義爲自包含的、可編程的、可重用的、與語言無關的軟件單元，軟件組件可以很容易被用於組裝應用程序中。
模塊和組件都是系統的組成部分，只是從不同的角度拆分系統而已。
從業務邏輯的角度來拆分系統後，得到的單元就是“模塊”；從物理部署的角度來拆分系統後，得到的單元就是“組件”。劃分模塊的主要目的是職責分離；劃分組件的主要目的是單元複用。
其實，“組件”的英文 Component 也可翻譯成中文的“零件”一詞。“零件”更容易理解一些，它是一個物理的概念，並且具備“獨立且可替換”的特點。
如果你是業務系統的架構師，首先需要思考怎麼從業務邏輯的角度把系統拆分成一個個模塊角色，其次需要思考怎麼從物理部署的角度把系統拆分成組件角色，例如選擇 MySQL 作爲存儲系統。但是對於 MySQL 內部的體系架構（Parser、Optimizer、Caches&Buffers 和 Storage Engines 等），你其實是可以不用關注的，也不需要在你的業務系統架構中展現這些內容。
框架與架構
框架是和架構比較相似的概念，且兩者有較強的關聯關係，所以在實際工作中，這兩個概念有時我們容易分不清楚。參考維基百科上框架與架構的定義，我來解釋兩者的區別。
軟件框架（Software framework）通常指的是爲了實現某個業界標準或完成特定基本任務的軟件組件規範，也指爲了實現某個軟件組件規範時，提供規範所要求之基礎功能的軟件產品。
1.框架是組件規範：例如，MVC 就是一種最常見的開發規範，類似的還有 MVP、MVVM、J2EE 等框架。
2.框架提供基礎功能的產品：例如，Spring MVC 是 MVC 的開發框架，除了滿足 MVC 的規範，Spring 提供了很多基礎功能來幫助我們實現功能，包括註解（@Controller 等）、Spring Security、Spring JPA 等很多基礎功能。軟件架構指軟件系統的“基礎結構”，創造這些基礎結構的準則，以及對這些結構的描述。
框架關注的是“規範”，架構關注的是“結構”。
重新定義架構：4R 架構
參考維基百科的定義，再結合我自己的一些理解和思考，我將軟件架構重新定義爲：軟件架構指軟件系統的頂層（Rank）結構，它定義了系統由哪些角色（Role）組成，角色之間的關係（Relation）和運作規則（Rule）。
因爲這個定義中的 4 個關鍵詞，都可以用 R 開頭的英文單詞來表示，分別是 Rank、Role、Relation 和 Rule，所以我把定義簡稱爲“4R 架構定義”，每個 R 的詳細解釋如下。第一個 R，Rank。它是指軟件架構是分層的，對應“系統”和“子系統”的分層關係。通常情況下，我們只需要關注某一層的架構，最多展示相鄰兩層的架構，而不需要把每一層的架構全部糅雜在一起。無論是架構設計還是畫架構圖，都應該採取“自頂向下，逐步細化”的方式。以微信爲例，Rank 的含義如下所示：
第二個 R，Role。它是指軟件系統包含哪些角色，每個角色都會負責系統的一部分功能。架構設計最重要的工作之一就是將系統拆分爲多個角色。最常見的微服務拆分其實就是將整體複雜的業務系統按照業務領域的方式，拆分爲多個微服務，每個微服務就是系統的一個角色。
第三個 R，Relation。它是指軟件系統的角色之間的關係，對應到架構圖中其實就是連接線，角色之間的關係不能亂連，任何關係最後都需要代碼來實現，包括連接方式（HTTP、TCP、UDP 和串口等）、數據協議（JSON、XML 和二進制等）以及具體的接口等。
第四個 R，Rule。它是指軟件系統角色之間如何協作來完成系統功能。我們在前面解讀什麼是“系統”的時候提到過：系統能力不是個體能力之和，而是產生了新的能力。那麼這個新能力具體如何完成的呢？具體哪些角色參與了這個新能力呢？這就是 Rule 所要表達的內容。在架構設計的時候，核心的業務場景都需要設計 Rule。