為什麼軟體架構缺乏明確定義？#

「Software architect」經常出現在各種最佳職業排行榜上，但與護理師或財務經理不同，這個職業卻沒有清晰的職涯路徑。原因有幾個：

• 業界缺乏共識的定義 — Martin Fowler 在著名的白皮書 “Who Needs an Architect?” 中也拒絕給出定義，而是引用 Ralph Johnson 的名言：“Architecture is about the important stuff…whatever that is.”
• 範圍持續擴大 — 十年前架構師只需處理純技術面（modularity、components、patterns），如今因為 microservices 等新架構風格，責任範圍大幅擴展
• 持續變動的目標 — 軟體開發生態系統快速演進，任何定義都可能很快過時
• 歷史包袱 — 過去許多架構相關的材料已失去時效性，許多曾經有效的方案在今天的脈絡下已不適用

所有架構都必須在其脈絡（context）下理解。許多架構決策是基於當時環境的現實限制，例如 2002 年建構 microservices 架構在成本上是不可能的，但開源軟體與 DevOps 革命改變了這一切。

定義軟體架構（Defining Software Architecture）#

作者提出軟體架構由四個面向組成：

Structure（結構）#

指系統實作所採用的 architecture style（架構風格），例如 microservices、layered、microkernel 等。

僅描述結構並不足以完整描述一個架構。如果有人問「你的架構是什麼？」而你回答「這是一個 microservices 架構」，你只描述了結構，而非完整的架構。

Architecture Characteristics（架構特性）#

定義系統的成功準則，通常與功能性需求正交（orthogonal）。這些特性又稱為 “-ilities”，包括：

• Availability（可用性）
• Reliability（可靠性）
• Scalability（可擴展性）
• Performance（效能）
• Security（安全性）
• Deployability（可部署性）
• Testability（可測試性）
• Elasticity（彈性）
• 以及更多…

架構特性不需要了解系統的功能需求，但系統要正常運作就必須支援這些特性。本書有數個章節專門探討架構特性的定義與治理。

Architecture Decisions（架構決策）#

定義系統建構的規則與限制。例如：在 layered architecture 中，只有 business 和 services 層可以存取資料庫，presentation 層不可直接呼叫資料庫。

• 架構決策構成系統的約束條件（constraints），指導開發團隊什麼可以做、什麼不可以做
• 當某個決策因特殊情況無法遵守時，可以透過 variance（變異）機制，經由 Architecture Review Board（ARB）或首席架構師審核後批准例外

Design Principles（設計原則）#

與架構決策不同，設計原則是指導方針（guideline）而非硬性規則（rule）。

例如：「服務之間應盡可能使用非同步訊息傳遞（async messaging）以提升效能」是一個設計原則，它提供偏好方向，但允許開發者在特定情境下選擇更合適的通訊協定（如 REST 或 gRPC）。

對架構師的期望（Expectations of an Architect）#

作者認為與其定義架構師的「角色」，不如聚焦在架構師的期望。無論職稱為何，軟體架構師有八項核心期望：

1. Make Architecture Decisions（做出架構決策）#

• 架構師應該引導（guide）技術選擇，而非指定（specify）技術選擇
• 例如：不應決定「使用 React.js」，而是決定「使用 reactive-based framework for frontend web development」，讓團隊在 Angular、React、Vue 之間選擇
• 關鍵問題：架構決策是在引導團隊做正確選擇，還是替團隊做技術選擇？

2. Continually Analyze the Architecture（持續分析架構）#

• 評估 architecture vitality — 三年前定義的架構在今天的業務和技術環境下是否仍然可行？
• 多數架構會經歷 structural decay（結構衰退），通常發生在開發者的程式碼變更影響了架構特性時
• 不要忘記分析測試環境和發布流程

3. Keep Current with Latest Trends（跟上最新趨勢）#

• 架構師的決策往往長期且難以更改，因此跟上技術趨勢有助於做出正確決策
• 追蹤趨勢很難，第 24 章討論了具體的技巧與資源

4. Ensure Compliance with Decisions（確保決策被遵守）#

• 持續驗證開發團隊是否遵循架構決策和設計原則
• 不確保合規性，架構特性就無法被滿足，系統也無法如預期運作
• 第 6 章介紹使用 automated fitness functions 來衡量合規性

5. Diverse Exposure and Experience（多元的技術接觸）#

• 不需要精通每一種技術，但至少要熟悉多種技術
• 重視技術廣度（technical breadth）而非技術深度（technical depth）
• 例如：熟悉 10 種 caching 產品的優缺點，比精通其中 1 種更有價值

6. Have Business Domain Knowledge（具備業務領域知識）#

• 沒有業務知識，就無法理解業務問題、目標和需求
• 最成功的架構師擁有廣泛的技術知識加上特定領域的深厚理解
• 這讓架構師能使用業務語言與 C-level 主管和業務使用者有效溝通

7. Possess Interpersonal Skills（具備人際技巧）#

• 領導力至少佔成為有效架構師所需能力的一半
• 架構師不僅要提供技術指導，還要帶領團隊完成架構的實作
• 許多技術優秀但缺乏領導力的架構師，難以維持其職位

8. Understand and Navigate Politics（理解並應對政治）#

• 架構師做的幾乎每個決策都會被挑戰 — 來自產品負責人、專案經理、業務利害關係人和開發者
• 與開發者不同，架構師的決策影響範圍更廣，因此必須為每個決策辯護
• 談判技巧極為關鍵，本書第 23 章專門討論

架構師的角色遠不只是技術能力。人際技巧、領導力、談判力和政治敏感度同樣重要，甚至更為關鍵。

架構的交叉領域（Intersection of Architecture and…）#

軟體架構的範圍在過去十年持續擴大，與組織其他部分的交集越來越多。

Engineering Practices（工程實踐）#

• 區分 process（流程）和 engineering practices（工程實踐）很重要
  • Process — 團隊如何組建、會議如何進行、工作流程如何運作
  • Engineering practices — 與流程無關的可重複實踐，如 continuous integration、automated testing
• 從 Extreme Programming（XP）到 Continuous Delivery 的演進，展示了工程實踐如何影響架構
• Unknown unknowns（未知的未知）是軟體系統的天敵，這就是為什麼 “Big Design Up Front” 方法會失敗
• 架構風格和工程實踐形成共生關係 — 例如 microservices 架構假設了自動化 machine provisioning、自動化測試和部署
• Fitness functions（適應度函數）來自 Building Evolutionary Architectures 一書，是對架構特性的客觀完整性評估，透過 metrics、unit tests、monitors 和 chaos engineering 等機制實作

架構風格與工程實踐必須匹配。試圖在缺乏自動化的傳統運維團隊中建構 microservices 架構，會造成巨大的摩擦。

Operations/DevOps#

• 過去架構與運維的關係是契約式的，許多公司將運維外包
• 舊有架構（如 ESB-driven SOA）被迫在架構內部處理 elastic scale 等運維關注點，導致架構更加複雜
• Microservices 的建構者意識到這些運維關注點應由 operations 處理，因此架構師與運維人員合作創造了 microservices

Process（流程）#

• 軟體架構大致上與開發流程正交，但流程會影響架構的許多面向
• Agile 方法論支援迭代式開發，提供更快的回饋循環，適合架構的本質
• 架構遷移（如從 monolithic 到更現代的架構）更適合 Agile 方法，搭配 Strangler Pattern 和 feature toggles 等技巧

All architectures become iterative because of unknown unknowns, Agile just recognizes this and does it sooner. — Mark Richards

Data#

• 程式碼與資料具有共生關係，兩者缺一不可
• 許多架構書籍對資料著墨甚少，但本書在討論架構的運維面向和 architectural quantum（第 3 章）時，會將資料庫等外部儲存納入考量

軟體架構的定律（Laws of Software Architecture）#

作者提出兩條軟體架構定律：

First Law#

Everything in software architecture is a trade-off.

軟體架構中的一切都是取捨。架構師面對的每個決策都必須考量多個對立因素。

Corollary 1（推論一）：If an architect thinks they have discovered something that isn’t a trade-off, more likely they just haven’t identified the trade-off yet.

如果你認為某個選擇沒有取捨，那很可能只是你還沒發現取捨在哪裡。

Second Law#

Why is more important than how.

「為什麼」比「怎麼做」更重要。架構師可以透過拓樸圖了解系統結構（how），但要理解為何做出特定選擇（why）則困難得多。本書全程強調架構師做出決策背後的 why 以及相關的取捨。