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

這個主題只有兩本，按有沒有詞彙分：《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 與這裡的架構風格處理的是同一件事的兩端。

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

具體的資料庫、快取、佇列與可觀測性選型看 Backend 服務實務指南，部署與環境看 Infra 基礎設施建置指南。