系統架構

Wed, 19 Aug 2026 00:00:00 +0800

架構決定跟設計判準與日常實踐與改既有的程式的差別在改錯的代價。程式碼寫得不好可以重構，模組切得不好可以搬；架構選錯之後，改動要跨越團隊、資料、部署與既有承諾，通常大到只能繞過而不能修正。這使得架構的核心能力是在資訊不足的時候把取捨講清楚——包括講清楚自己選的那個爛在哪——而不是知道有哪些做法。

這個主題只有兩本，按有沒有詞彙分：《Fundamentals of Software Architecture》先建立一整套可以用來討論的概念，《Software Architecture: The Hard Parts》再處理那些用了概念仍然沒有標準答案的決定。

讀不動長篇文字時，本篇文末另標出承接這個主題機制層的公開課，收錄門檻與已知限制見書單推薦的「公開課怎麼收」段。

起點是 Fundamentals of Software Architecture

Mark Richards 與 Neal Ford 這本的主要貢獻是一整套詞彙，而詞彙要鋪滿才有用——這也是它成為本篇涵蓋面最完整一本的原因。沒有那套詞彙的架構討論會停在「我覺得微服務比較好」，有了之後才問得出「我們要優化的是哪幾個架構特性、代價付在哪裡」。

核心是架構特性（architecture characteristics）這個概念：可擴展性、彈性、可測試性、可部署性這些「性」不是越多越好，它們互相衝突，而架構的工作是選出這個系統真正需要的少數幾個、明確放棄其餘的。書中另一半是架構風格的目錄——分層、微核心、事件驅動、微服務、第二版新增的模組化單體——每個風格附上它在各項特性上的評分，於是「選哪個」變成一個有維度的比較而不是流行度投票。

第二版（繁中版 2026 年出）跟第一版的差距大到需要挑版本：新增模組化單體、架構模式、圖示法、治理、資料架構與生成式 AI 幾章，並改寫了架構法則的部分。第一版繁中譯名是《軟體架構原理｜工程方法》，第二版是《軟體架構原理第二版｜現代工程方法》，買新的。

時效上，架構風格的清單與各風格的特性評分隨生態變動——第二版新增的模組化單體與生成式 AI 兩章就是這一層的更新；架構特性互相衝突、必須明確放棄一些，這條主軸不依賴任何一代的風格清單。證據來源是跨客戶的顧問經驗與教學經驗，加上跨組織案例的整理，形式接近教科書——它整理已知的做法而非提出新主張，這也決定了它的用法：當參照系用，不是當論證用。

處境相容性上，架構特性的取捨預設有人為不同特性負責、而且那些人講得上話。決定由外部給定時——客戶指定、母公司統一、法規要求——這本書給的是理解那個決定的語言，不是做那個決定的方法。

讀這本要參與過一個需要跨團隊協調的系統，架構特性的衝突才體會得到——衝突要在有人為不同特性負責時才顯現，只在單一服務裡工作時看不見它。

已經在拆分而每個選項都有代價時讀 Software Architecture: The Hard Parts

同一組作者加上 Pramod Sadalage 與 Zhamak Dehghani 的這本，處理的是前一本建立詞彙之後才浮出來的問題：服務該切多細、工作流程要編排還是編舞、契約要嚴格還是寬鬆、分散式交易怎麼辦、資料該怎麼跟著服務拆。

它的書名說明了立場——這些是沒有最佳實踐的問題。書的結構因此給的是取捨分析的做法而非答案：把每個決定的可能選項列出來、標出各自在哪些架構特性上得分、明確寫出放棄了什麼。它反覆示範同一個動作，那個動作本身才是要學的東西。

其中資料那部分特別值得注意，因為它是拆分服務時最常被低估的一段。服務可以切開，資料的一致性需求切不開；書中對於哪些資料該複製、哪些該共用、交易邊界該畫在哪，給的是可以逐項走的判斷，而不是「盡量避免分散式交易」這種沒有出口的建議。

它跟前一本的關係是入場與深水：前一本讓人說得出這個系統要什麼，這本接手說得出之後仍然沒有標準答案的那些決定。順序不要顛倒——沒有架構特性的詞彙時，這本的取捨分析會讀成一堆並列的技術選項。

證據來源同樣是跨客戶的顧問經驗加跨組織案例，而它比前一本更依賴一個貫穿全書的虛構案例。時效上，書出版於 2021 年，微服務相關的工具生態已有變化；取捨分析的做法與資料拆分的判斷不依賴那些工具。

這本要有正在拆、或已經拆了一個系統的處境才讀得出東西——沒有那個處境時，八種粒度崩解訊號每一種都同樣有道理，而它們的用途是在其中認出正在發生的那一種。可以先知道它存在，開始拆的時候再拿出來。繁體中文版《軟體架構：困難部分》。

為什麼只收這兩本

兩本按「有沒有詞彙」分：建立整套概念與參照系（Fundamentals），以及用了概念之後仍然沒有標準答案的決定（The Hard Parts）。同一組作者，刻意寫成前後接續，中間沒有空隙也沒有重疊。

架構的書市有一大類是特定架構風格的推廣書（微服務怎麼做、事件驅動怎麼做）。那類的問題是它們預設風格已經選定，而選擇本身才是架構工作最難的部分——分辨方式是看它有沒有寫「什麼情況下不要用這個風格」，而架構風格的邊界通常落在規模與團隊數上——同一個風格在三個團隊與三十個團隊下的代價差一個量級，不交代這一項的多半是在推銷而不是在分析。

Robert Martin 的《Clean Architecture》常被列在這個位置，本書單未評估它，理由與設計判準與日常實踐對《Clean Code》的處理相同。SEI 的《Software Architecture in Practice》是學術系統化的另一條路線（品質屬性、ATAM 評估法），繁中版也在，但它的讀者定位偏向需要正式架構評估流程的組織，本書單未評估那個情境。

資料密集系統的設計（複製、分片、一致性模型）不在這個主題，那屬於 Backend 服務實務指南的責任範圍。

機制那一半有兩門完整的課，取捨判斷那一半沒有

這是技藝線唯一接得住公開課的主題，而它接住的只有一半。架構決定要用到機制知識與取捨判斷兩者：機制知識是複製怎麼做、一致性有幾種、共識協定在解什麼、分割之後交易怎麼辦；取捨判斷是在資訊不足時把每個選項的代價講清楚。機制教得了，判斷教不了——這跟本篇兩本書的分工同向，起點書先給詞彙、第二本才處理用了詞彙仍然沒有標準答案的決定。

MIT 6.824 Distributed Systems（Spring 2020） 由 Robert Morris 主講、20 講、每講約 80 分鐘，走的是讀論文加講解的形式。講次依序走過 GFS、主備複製、Raft（連三講）、ZooKeeper、CRAQ 的鏈式複製、Aurora、Frangipani 與 Memcached 的快取一致性、分散式交易、Spanner、樂觀並行控制、Spark、COPS 的因果一致性，最後兩講是 Bitcoin 與 Blockstack。它給的是本篇兩本書在談元件切分與資料所有權時預設讀者知道、而兩本書都不從頭建立的那些機制。這門課要寫 Go 的實驗作業（MapReduce 與 Raft 各一份），只看講課不做實驗仍然走得完，代價是共識協定那幾講會停在聽得懂而不是做得出來。

Martin Kleppmann 的 Distributed Systems lecture series 是劍橋的課，8 講切成 23 段影片、每段 10 到 20 分鐘，全長約七小時。同一位作者的《Designing Data-Intensive Applications》不在這一篇——資料密集系統的設計屬於 Backend 服務實務指南的範圍，這裡收的只有這門課。它跟前一門的差別在密度與門檻：Morris 那門一講一篇論文、每講約 80 分鐘、假設聽眾是研究生；Kleppmann 這門從電腦網路與時鐘開始建立，單段短、可以零碎聽完。兩門的「講」不是同一個單位——比長度要用總時數，6.824 二十講約二十六小時。想先建立整體地圖的從這一門開始，想追某個機制怎麼被證明的走前一門。

兩門課的材料是已經發表的論文與已經定案的協定，時效因此不隨版本更新而動；會改變的是它們順帶提到的雲端服務與工具介面。兩門都是英語授課，而它們不像 Open Yale 的課附官方逐字稿——字幕狀態以 YouTube 當下提供的為準，本頁沒有確認過是人工還是自動。這個主題沒查到中文的對應課。

取捨判斷那一半沒查到課，而缺口的成因就是這個主題的核心能力本身——在資訊不足的時候把取捨講清楚，包括講清楚自己選的那個爛在哪。這種能力的教材是別人做過的決定與它後來的代價，而那些代價要好幾年才顯現，一學期的課承載不了。整條線的供給狀況寫在工程技藝書單的公開課段。

這個主題接到哪裡

架構決定的代價一半落在組織上——介面畫在哪裡，決定了哪兩個團隊要天天開會。那條路徑走組織結構與團隊設計，Team Topologies 與這裡的架構風格處理的是同一件事的兩端。

往下一個尺度走，模組與介面該怎麼切看設計判準與日常實踐；架構定了之後既有程式碼怎麼搬過去看改既有的程式。