架構思維概述#

架構思維 (Architectural Thinking) 不只是「懂架構」，而是用架構師的角度看待整個軟體系統。本章涵蓋四個核心面向：架構與設計的關係、技術廣度與深度的平衡、Trade-off 分析、以及如何在架構與實作之間取得平衡。

Architecture Versus Design#

傳統模型的問題#

傳統觀點將 architecture 和 design 視為兩個分離的活動：架構師負責定義架構特性 (architecture characteristics)、架構風格 (architecture style) 和元件結構 (component structure)，然後單向地「丟過牆」給開發者去做 class design、UI 和 source code。

這個模型的根本問題在於單向箭頭：

  • 架構師的決策有時無法傳達到開發團隊
  • 開發團隊做出影響架構的決策，卻很少回饋給架構師
  • 架構師與開發團隊脫節，架構最終無法實現原本的目標

協作模型#

要讓架構真正運作，必須打破架構師與開發者之間的實體和虛擬屏障，建立雙向關係。架構師和開發者應該在同一個虛擬團隊中，這不僅促進雙向溝通，也讓架構師能對團隊進行 mentoring 和 coaching。

Architecture 和 design 沒有明確的分界線。它們都是軟體專案生命週期的一部分，必須始終保持同步才能成功。

Figure 2.2: Making architecture work through collaboration

Technical Breadth#

知識金字塔#

每個人的技術知識可以分為三個層次：

  • Stuff you know — 日常使用的技術、框架和工具（例如熟練使用 Java）
  • Stuff you know you don’t know — 聽過但沒有深入了解的技術（例如知道 Clojure 是基於 Lisp 的語言，但不會寫）
  • Stuff you don’t know you don’t know — 金字塔中最大的部分，完全不知道其存在的技術和解決方案

Figure 2.3: The pyramid representing all knowledge

開發者 vs 架構師的知識策略#

開發者的職涯早期應專注於擴展金字塔頂端，累積 technical depth（技術深度）。頂端的知識也是需要持續維護的知識 — 軟體世界沒有什麼是靜態的。

Figure 2.4: Developers must maintain expertise to retain it

架構師的價值在於對技術的廣泛理解。知道某個問題有五種解法，比只精通其中一種更有價值。因此架構師需要：

  • 犧牲部分深度專業知識，換取更廣的 technical breadth（技術廣度）
  • 保留少數專精領域 (areas of specialization)，讓其他領域自然淡化
  • 中間層（stuff you know you don’t know）向底層的滲透程度，代表架構師的技術廣度

Figure 2.6: Enhanced breadth and shrinking depth for the architect role

轉型為架構師時常見兩種失調：

  1. 試圖在所有領域維持專業，結果疲於奔命卻一無所長
  2. Stale expertise — 誤以為過時的知識仍然是前沿技術

Frozen Caveman Anti-Pattern#

Frozen Caveman Anti-Pattern 描述的是架構師因為過去的某次慘痛經驗，對每個架構都執著於同一個不相關的顧慮。例如，因為多年前一次義大利門市的通訊故障，每次審查架構都要問「但如果我們失去義大利怎麼辦？」

風險評估很重要，但也必須務實。區分真正的技術風險與感知到的技術風險，是架構師持續學習的一部分。

Analyzing Trade-Offs#

一切都是 Trade-Off#

Architecture is the stuff you can’t Google. — Mark Richards

There are no right or wrong answers in architecture — only trade-offs. — Neal Ford

軟體架構中的每個問題答案都是 “it depends”。你無法 Google 出 REST 還是 messaging 比較好，也無法查到 microservices 是否是正確選擇 — 因為答案取決於部署環境、業務驅動、公司文化、預算、時間、開發者技能等眾多因素。

實例：Topic vs Queue#

以拍賣系統為例，Bid Producer 需要將出價資訊發送給 Bid Capture、Bid Tracking 和 Bid Analytics 三個服務。可以使用 topic（publish-subscribe）或 queue（point-to-point）。

Figure 2.7: Auction system example of a trade-off — queues or topics?

Topic 的優點：

  • Architectural extensibility — 新增服務只需訂閱既有 topic，無需修改現有系統
  • Service decoupling — Bid Producer 不需要知道誰在使用資料

Figure 2.8: Use of a topic for communication between services

Topic 的缺點：

  • 資料存取與安全性 — 任何訂閱者都能存取資料，容易被竊聽
  • No heterogeneous contracts — 所有消費者必須接受相同的資料格式
  • Monitoring and programmatic scalability — 不支援個別監控與自動擴展

Queue 的優點與缺點正好相反。

Figure 2.9: Use of queues for communication between services

引用 Rich Hickey 的話：Programmers know the benefits of everything and the trade-offs of nothing. Architects need to understand both.

架構思維不僅要看到方案的好處，更要分析其負面影響和 trade-off。

如何做決策#

重點不在於哪個方案「正確」，而是分析 trade-off 後，根據業務驅動和環境因素，問出正確的問題：「extensibility 和 security 哪個更重要？」

Understanding Business Drivers#

架構思維的一個重要面向是理解系統成功所需的業務驅動因素，並將其轉化為架構特性（如 scalability、performance、availability）。這需要架構師：

  • 具備一定程度的業務領域知識
  • 與關鍵業務利害關係人建立健康的協作關係

本書在 Chapter 4 定義各種架構特性，Chapter 5 描述如何識別和量化它們，Chapter 6 描述如何測量以確保滿足業務需求。

Balancing Architecture and Hands-On Coding#

每個架構師都應該維持一定程度的 coding 能力。以下是實踐建議：

避免 Bottleneck Trap#

Bottleneck trap 發生在架構師負責專案的 critical path code（通常是 framework code），卻因為無法全職開發而成為團隊瓶頸。

解決方式：將 critical path 和 framework code 委派給開發團隊，架構師則專注於未來一到三個迭代的業務功能開發。這樣做有三個好處：

  • 架構師獲得實作經驗但不會成為瓶頸
  • 開發團隊擁有關鍵程式碼的 ownership
  • 架構師能更理解開發團隊的痛點

四種保持 Hands-On 的方式#

如果架構師無法與開發團隊一起寫程式碼，仍有四種方式保持技術深度：

  1. 做 Proof-of-Concept (POC) — 驗證架構決策，同時比較不同方案的實作細節。盡量寫 production-quality 的 POC 程式碼，因為它很可能被當作參考範例
  2. 處理 technical debt 或 architecture stories — 這些通常是低優先級任務，即使無法在迭代內完成也不影響大局
  3. 修 bug — 雖然不光鮮，但能幫助架構師發現程式碼中的問題和弱點
  4. 建立自動化工具 — 為團隊創建 command-line 工具和分析器，例如自動化的 source validator、coding standard 檢查、架構合規性測試（如 ArchUnit、fitness functions）
Backward Introduction Modularity Forward