程式的世界飛速發展，今天所掌握的技能可能明年就過時了，但有一些東西是歷久彌新，永遠不變的，掌握了這些，在程式的海洋裡就不會迷路，架構思想就是這樣一種東西。

本文是《架構整潔之道》的讀書筆記，文章從軟體系統的價值出發，認識架構工作的價值和目標， 依次瞭解架構設計的基礎、指導思想（設計原則）、元件拆分的方法和粒度、元件之間依賴設計、元件邊界多種解耦方式以及取捨、降低元件之間通訊成本的方法，從而在做出正確的架構決策和架構設計方面，給出作者自己的解讀。

阿里巴巴中介軟體微信公眾號對話方塊，傳送“架構”，可獲取《架構整潔之道》知識脈絡圖。

一、軟體系統的價值

架構是軟體系統的一部分，所以要明白架構的價值，首先要明確軟體系統的價值。軟體系統的價值有兩方面，行為價值和架構價值。

行為價值是軟體的核心價值，包括需求的實現，以及可用性保障（功能性 bug 、效能、穩定性）。這幾乎佔據了我們90%的工作內容，支撐業務先贏是我們工程師的首要責任。如果業務是明確的、穩定的，架構的價值就可以忽略不計，但業務通常是不明確的、飛速發展的，這時架構就無比重要，因為架構的價值就是讓我們的軟體（Software）更軟（Soft）。可以從兩方面理解：

• 當需求變更時，所需的軟體變更必須簡單方便。
• 變更實施的難度應該和變更的範疇（scope）成等比，而與變更的具體形狀（shape）無關。

當我們只關注行為價值，不關注架構價值時，會發生什麼事情？這是書中記錄的一個真實案例，隨著版本迭代，工程師團隊的規模持續增長，但總程式碼行數卻趨於穩定，相對應的，每行程式碼的變更成本升高、工程師的生產效率降低。從老闆的視角，就是公司的成本增長迅猛，如果營收跟不上就要開始賠錢啦。

可見架構價值重要性，接下來從著名的緊急重要矩陣出發，看我們如何處理好行為價值和架構價值的關係。

重要緊急矩陣中，做事的順序是這樣的：1.重要且緊急 > 2.重要不緊急 > 3.不重要但緊急 > 4.不重要且不緊急。實現行為價值的需求通常是 PD 提出的，都比較緊急，但並不總是特別重要；架構價值的工作內容，通常是開發同學提出的，都很重要但基本不是很緊急，短期內不做也死不了。所以行為價值的事情落在1和3（重要且緊急、不重要但緊急），而架構價值落在2（重要不緊急）。我們開發同學，在低頭敲程式碼之前，一定要把雜糅在一起的1和3分開，把我們架構工作插進去。
 

二、架構工作的目標

前面講解了架構價值，追求架構價值就是架構工作的目標，說白了，就是用最少的人力成本滿足構建和維護該系統的需求，再細緻一些，就是支撐軟體系統的全生命週期，讓系統便於理解、易於修改、方便維護、輕鬆部署。對於生命週期裡的每個環節，優秀的架構都有不同的追求：

• 開發階段：元件不要使用大量複雜的腳手架；不同團隊負責不同的元件，避免不必要的協作。
• 部署階段：部署工作不要依賴成堆的指令碼和配置檔案；元件越多部署工作越繁重，而部署工作本身是沒有價值的，做的越少越好，所以要減少元件數量。
• 執行階段：架構設計要考慮到不同的吞吐量、不同的響應時長要求；架構應起到揭示系統執行的作用：用例、功能、行為設定應該都是對開發者可見的一級實體，以類、函式或模組的形式佔據明顯位置，命名能清晰地描述對應的功能。
• 維護階段：減少探祕成本和風險。探祕成本是對現有軟體系統的挖掘工作，確定新功能或修復問題的最佳位置和方式。風險是做改動時，可能衍生出新的問題。
   

三、程式設計正規化

其實所謂架構就是限制，限制原始碼放在哪裡、限制依賴、限制通訊的方式，但這些限制比較上層。程式設計正規化是最基礎的限制，它限制我們的控制流和資料流：結構化程式設計限制了控制權的直接轉移，面向物件程式設計限制了控制權的間接轉移，函數語言程式設計限制了賦值，相信你看到這裡一定一臉懵逼，啥叫控制權的直接轉移，啥叫控制權的間接轉移，不要著急，後邊詳細講解。

這三個程式設計正規化最近的一個也有半個世紀的歷史了，半個世紀以來沒有提出新的程式設計正規化，以後可能也不會了。因為程式設計正規化的意義在於限制，限制了控制權轉移限制了資料賦值，其他也沒啥可限制的了。很有意思的是，這三個程式設計正規化提出的時間順序可能與大家的直覺相反，從前到後的順序為：函數語言程式設計（1936年）、面向物件程式設計（1966年）、結構化程式設計（1968年）。

1.結構化程式設計

結構化程式設計證明了人們可以用順序結構、分支結構、迴圈結構這三種結構構造出任何程式，並限制了 goto 的使用。遵守結構化程式設計，工程師就可以像數學家一樣對自己的程式進行推理證明，用程式碼將一些已證明可用的結構串聯起來，只要自行證明這些額外程式碼是確定的，就可以推匯出整個程式的正確性。

前面提到結構化程式設計對控制權的直接轉移進行了限制，其實就是限制了 goto 語句。什麼叫做控制權的直接轉移？就是函式呼叫或者 goto 語句，程式碼在原來的流程裡不繼續執行了，轉而去執行別的程式碼，並且你指明瞭執行什麼程式碼。為什麼要限制 goto 語句？因為 goto 語句的一些用法會導致某個模組無法被遞迴拆分成更小的、可證明的單元。而採用分解法將大型問題拆分正是結構化程式設計的核心價值。

其實遵守結構化程式設計，工程師們也無法像數學家那樣證明自己的程式是正確的，只能像物理學家一樣，說自己的程式暫時沒被證偽（沒被找到bug）。數學公式和物理公式的最大區別，就是數學公式可被證明，而物理公式無法被證明，只要目前的實驗資料沒把它證偽，我們就認為它是正確的。程式也是一樣，所有的 test case 都通過了，沒發現問題，我們就認為這段程式是正確的。

2.面向物件程式設計

面向物件程式設計包括封裝、繼承和多型，從架構的角度，這裡只關注多型。多型讓我們更方便、安全地通過函式呼叫的方式進行元件間通訊，它也是依賴反轉（讓依賴與控制流方向相反）的基礎。

在非面向物件的程式語言中，我們如何在互相解耦的元件間實現函式呼叫？答案是函式指標。比如採用C語言編寫的作業系統中，定義瞭如下的結構體來解耦具體的IO裝置， IO 裝置的驅動程式只需要把函式指標指到自己的實現就可以了。

struct FILE {
    void (*open)(char* name, int mode);
    void (*close)();
    int (*read)();
    void (*write)(char);
    void (*seek)(long index, int mode);
}

這種通過函式指標進行元件間通訊的方式非常脆弱，工程師必須嚴格按照約定初始化函式指標，並嚴格地按照約定來呼叫這些指標，只要一個人沒有遵守約定，整個程式都會產生極其難以跟蹤和消除的 Bug。所以面向物件程式設計限制了函式指標的使用，通過介面-實現、抽象類-繼承等多型的方式來替代。

前面提到面向物件程式設計對控制權的間接轉移進行了限制，其實就是限制了函式指標的使用。什麼叫做控制權的間接轉移？就是程式碼在原來的流程裡不繼續執行了，轉而去執行別的程式碼，但具體執行了啥程式碼你也不知道，你只調了個函式指標或者介面。

3.函數語言程式設計

函數語言程式設計有很多種定義很多種特性，這裡從架構的角度，只關注它的沒有副作用和不修改狀態。函數語言程式設計中，函式要保持獨立，所有功能就是返回一個新的值，沒有其他行為，尤其是不得修改外部變數的值。前面提到函數語言程式設計對賦值進行了限制，指的就是這個特性。

在架構領域所有的競爭問題、死鎖問題、併發問題都是由可變變數導致的。如果有足夠大的儲存量和計算量，應用程式可以用事件溯源的方式，用完全不可變的函數語言程式設計，只通過事務記錄從頭計算狀態，就避免了前面提到的幾個問題。目前要讓一個軟體系統完全沒有可變變數是不現實的，但是我們可以通過將需要修改狀態的部分和不需要修改的部分分隔成單獨的元件，在不需要修改狀態的元件中使用函數語言程式設計，提高系統的穩定性和效率。

綜上，沒有結構化程式設計，程式就無法從一塊塊可證偽的邏輯搭建，沒有面向物件程式設計，跨越元件邊界會是一個非常麻煩而危險的過程，而函數語言程式設計，讓元件更加高效而穩定。沒有程式設計正規化，架構設計將無從談起。
 

四、設計原則

和程式設計正規化相比，設計原則和架構的關係更加緊密，設計原則就是架構設計的指導思想，它指導我們如何將資料和函式組織成類，如何將類連結起來成為元件和程式。反向來說，架構的主要工作就是將軟體拆解為元件，設計原則指導我們如何拆解、拆解的粒度、元件間依賴的方向、元件解耦的方式等。

設計原則有很多，我們進行架構設計的主導原則是 OCP（開閉原則），在類和程式碼的層級上有：SRP（單一職責原則）、LSP（里氏替換原則）、ISP（介面隔離原則）、DIP（依賴反轉原則）；在元件的層級上有：REP（複用、釋出等同原則）、 CCP（共同閉包原則）、CRP（共同複用原則），處理元件依賴問題的三原則：無依賴環原則、穩定依賴原則、穩定抽象原則。

1.OCP（開閉原則）

設計良好的軟體應該易於擴充套件，同時抗拒修改。這是我們進行架構設計的主導原則，其他的原則都為這條原則服務。

2.SRP（單一職責原則）

任何一個軟體模組，都應該有且只有一個被修改的原因，“被修改的原因“指系統的使用者或所有者，翻譯一下就是，任何模組只對一個使用者的價值負責。該原則指導我們如何拆分元件。

舉個例子，CTO 和 COO 都要統計員工的工時，當前他們要求的統計方式可能是相同的，我們複用一套程式碼，這時 COO 說週末的工時統計要乘以二，按照這個需求修改完程式碼，CTO 可能就要過來罵街了。當然這是個非常淺顯的例子，實際專案中也有很多程式碼服務於多個價值主體，這帶來很大的探祕成本和修改風險。

另外當一份程式碼有多個所有者時，就會產生程式碼合併衝突的問題。

3.LSP（里氏替換原則）

當用同一介面的不同實現互相替換時，系統的行為應該保持不變。該原則指導的是介面與其實現方式。

你一定很疑惑，實現了同一個介面，他們的行為也肯定是一致的呀，還真不一定。假設認為矩形的系統行為是：面積=寬*高，讓正方形實現矩形的介面，在呼叫 setW 和 setH 時，正方形做的其實是同一個事情，設定它的邊長。這時下邊的單元測試用矩形能通過，用正方形就不行，實現同樣的介面，但是系統行為變了，這是違反 LSP 的經典案例。

Rectangle r = ...
r.setW(5);
r.setH(2);
assert(r.area() == 10);

4.ISP（介面隔離原則）

不依賴任何不需要的方法、類或元件。該原則指導我們的介面設計。

當我們依賴一個介面但只用到了其中的部分方法時，其實我們已經依賴了不需要的方法或類，當這些方法或類有變更時，會引起我們類的重新編譯，或者引起我們元件的重新部署，這些都是不必要的。所以我們最好定義個小介面，把用到的方法拆出來。

5.DIP（依賴反轉原則）

跨越組建邊界的依賴方向永遠與控制流的方向相反。該原則指導我們設計元件間依賴的方向。

依賴反轉原則是個可操作性非常強的原則，當你要修改元件間的依賴方向時，將需要進行元件間通訊的類抽象為介面，介面放在邊界的哪邊，依賴就指向哪邊。

6.REP（複用、釋出等同原則）

軟體複用的最小粒度應等同於其釋出的最小粒度。直白地說，就是要複用一段程式碼就把它抽成元件。該原則指導我們元件拆分的粒度。

7.CCP（共同閉包原則）

為了相同目的而同時修改的類，應該放在同一個元件中。CCP 原則是 SRP 原則在元件層面的描述。該原則指導我們元件拆分的粒度。

對大部分應用程式而言，可維護性的重要性遠遠大於可複用性，由同一個原因引起的程式碼修改，最好在同一個元件中，如果分散在多個元件中，那麼開發、提交、部署的成本都會上升。

8.CRP（共同複用原則）

不要強迫一個元件依賴它不需要的東西。CRP 原則是 ISP 原則在元件層面的描述。該原則指導我們元件拆分的粒度。

相信你一定有這種經歷，集成了元件A，但元件A依賴了元件B、C。即使元件B、C 你完全用不到，也不得不整合進來。這是因為你只用到了元件A的部分能力，元件A中額外的能力帶來了額外的依賴。如果遵循共同複用原則，你需要把A拆分，只保留你要用的部分。

REP、CCP、CRP 三個原則之間存在彼此競爭的關係，REP 和 CCP 是黏合性原則，它們會讓元件變得更大，而 CRP 原則是排除性原則，它會讓元件變小。遵守REP、CCP 而忽略 CRP ，就會依賴了太多沒有用到的元件和類，而這些元件或類的變動會導致你自己的元件進行太多不必要的釋出；遵守 REP 、CRP 而忽略 CCP，因為元件拆分的太細了，一個需求變更可能要改n個元件，帶來的成本也是巨大的。

優秀的架構師應該能在上述三角形張力區域中定位一個最適合目前研發團隊狀態的位置，例如在專案早期，CCP比REP更重要，隨著專案的發展，這個最合適的位置也要不停調整。

9.無依賴環原則

健康的依賴應該是個有向無環圖（DAG），互相依賴的元件，實際上組成了一個大元件，這些元件要一起釋出、一起做單元測試。我們可以通過依賴反轉原則 DIP 來解除依賴環。

10.穩定依賴原則

依賴必須要指向更穩定的方向。

這裡元件的穩定性指的是它的變更成本，和它變更的頻繁度沒有直接的關聯（變更的頻繁程度與需求的穩定性更加相關）。影響元件的變更成本的因素有很多，比如元件的程式碼量大小、複雜度、清晰度等等，最最重要的因素是依賴它的元件數量，讓元件難以修改的一個最直接的辦法就是讓很多其他元件依賴於它！

元件穩定性的定量化衡量指標是：不穩定性（I） = 出向依賴數量 / (入向依賴數量 + 出向依賴數量)。如果發現違反穩定依賴原則的地方，解決的辦法也是通過 DIP 來反轉依賴。

11.穩定抽象原則

一個元件的抽象化程度應該與其穩定性保持一致。為了防止高階架構設計和高階策略難以修改，通常抽象出穩定的介面、抽象類為單獨的元件，讓具體實現的元件依賴於介面元件，這樣它的穩定性就不會影響它的擴充套件性。

元件抽象化程度的定量化描述是：抽象程度（A）= 元件中抽象類和介面的數量 / 元件中類的數量。

將不穩定性（I）作為橫軸，抽象程度（A）作為縱軸，那麼最穩定、只包含抽象類和介面的元件應該位於左上角（0，1），最不穩定、只包含具體實現類，沒有任何介面的元件應該位於右下角（1，0），他們連線就是主序列線，位於線上的元件，他們的穩定性和抽象程度相匹配，是設計良好的元件。位於（0，0）周圍區域的元件，它們是非常穩定（注意這裡的穩定指的是變更成本）並且非常具體的元件，因為他們的抽象程度低，決定了他們經常改動的命運，但是又有許多其他元件依賴他們，改起來非常痛苦，所以這個區域叫做痛苦區。右上角區域的元件，沒有其他元件依賴他們，他們自身的抽象程度又很高，很有可能是陳年的老程式碼，所以這個區域叫做無用區。

另外，可以用點距離主序列線的距離 Z 來表示元件是否遵循穩定抽象原則，Z 越大表示元件越違背穩定依賴原則。

五、架構工作的基本方針

瞭解了程式設計正規化和設計原則，接下來我們看看如何應用他們拆分元件、處理元件依賴和元件邊界。架構工作有兩個方針：

儘可能長時間地保留儘可能多的可選項。這裡的可選項指的是無關緊要的細節設計，比如具體選用哪個儲存方式、哪種資料庫，或者採用哪種 Web 框架。業務程式碼要和這些可選項解耦，資料庫或者框架應該做到像外掛一樣切換，業務層對這個切換的過程應該做到完全無感。

低層次解耦方式能解決的，不要用高層次解耦方式。元件之間的解耦方式後邊細講，這裡強調的是邊界處理越完善，開發和部署成本越高。所以不完全邊界能解決的，不要用完全邊界，低層次解耦能解決的，不要用高層次解耦。

六、元件的拆分

首先要給元件下個定義：元件是一組描述如何將輸入轉化為輸出的策略語句的集合，在同一個元件中，策略的變更原因、時間、層次相同。

從定義就可以看出，元件拆分需要在兩個維度進行：按層次拆分、按變更原因拆分。

這裡的變更原因就是業務用例，按變更原因進行元件拆分的例子是：訂單元件、聊天元件。按層次拆分，可以拆為：業務實體、用例、介面介面卡、框架與驅動程式。

• 業務實體：關鍵業務資料和業務邏輯的集合，與介面無關、與儲存無關、與框架無關，只有業務邏輯。
• 用例：特定場景下的業務邏輯，可以理解為 輸入 + 業務實體 + 輸出 = 用例。
• 介面介面卡：包含整個整個MVC，以及對儲存、裝置、介面等的介面宣告和使用。

一條策略距離系統的輸入、輸出越遠，它的層次越高，所以業務實體是最高的層，框架與驅動程式是最低的層。

七、元件依賴處理

前面拆好了元件分好了層，依賴就很好處理了：依賴關係與資料流控制流脫鉤，而與元件所在層次掛鉤，始終從低層次指向高層次，如下圖。越具體的策略處在的層級越低，越外掛化。切換資料庫是框架驅動層的事情，介面介面卡完全無感知，切換展示器是介面介面卡層面的事情，用例完全無感知，而切換用例也不會影響到業務實體。

八、元件邊界處理

一個完整的元件邊界包括哪些內容？首先跨越元件邊界進行通訊的兩個類都要抽象為介面，另外需要宣告專用的輸入資料模型、宣告專用的返回資料模型，想一想每次進行通訊時都要進行的資料模型轉換，就能理解維護一個元件邊界的成本有多高。

除非必要，我們應該儘量使用不完全邊界來降低維護元件邊界的成本。不完全邊界有三種方式：

• 省掉最後一步：宣告好介面，做好分割後，仍然放在一個元件中，等到時機成熟時再拆出來獨立編譯部署。
• 單向邊界：正常的邊際至少有兩個介面，分別抽象呼叫方和被呼叫方。這裡只定義一個介面，高層次元件用介面呼叫低層次元件，而低層次元件直接引用高層次元件的類。
• 門戶模式：控制權的間接轉移不用介面和實現去做，而是用門戶類去做，用這種方式連線口都不用聲明瞭。

除了完全邊界和不完全邊界的區分，邊界的解耦方式也可以分為3個層次：

• 原始碼層次：做了介面、類依賴上的解耦，但是放在同一個元件中，通常放在不同的路徑下。和不完全邊界的省略最後一步一樣。
• 部署層次：拆分為可以獨立部署的不同元件，比如 iOS 的靜態庫、動態庫，真正執行時處於同一臺物理機器上，元件之間通常通過函式呼叫通訊。
• 服務層次：執行在不同的機器上，通過 url 、網路資料包等方式進行通訊。

從上到下，（開發、部署）成本依次升高，如果低層次的解耦已經滿足需要，不要進行高層次的解耦。

原文連結
本文為雲棲社群原創內容，未經