概述#

辨識驅動架構的關鍵特性（driving architecture characteristics）是建立架構或驗證現有架構的第一步。架構師至少透過三種方式來發掘架構特性：

• 從 domain concerns（領域關注點）中萃取
• 從 requirements（需求）中萃取
• 運用 implicit domain knowledge（隱性領域知識）

Extracting Architecture Characteristics from Domain Concerns#

架構師必須能將領域關注點轉譯為正確的架構特性。例如：scalability 是最重要的考量？還是 fault tolerance、security 或 performance？也許系統需要同時具備這四者。

保持清單精簡#

一個常見的反模式是設計 generic architecture — 試圖支援所有架構特性的通用架構。每多支援一個特性就會增加系統複雜度。不要執著於特性的數量，而要致力於保持設計簡潔。

讓 domain stakeholders 從最終清單中選出最重要的前三項（不需排序）是一個實用的方法。這不僅更容易達成共識，也有助於架構師在做 trade-off 決策時有明確依據。

Vasa 號的教訓#

書中提到瑞典 Vasa 戰艦的案例：1626-1628 年建造，國王要求它同時是運兵船和砲艦、有兩層砲甲板、火砲比同類船隻大一倍。結果首航就因頭重腳輕而翻覆沉沒。這是過度指定架構特性、最終導致專案失敗的經典案例。

領域關注點與架構特性的對應#

架構師與 domain stakeholders 說的是不同的語言：架構師談 scalability、fault tolerance，利害關係人談 mergers、user satisfaction、time to market。兩者之間需要「翻譯」。

Agility 不等於 time to market。 Agility = agility + testability + deployability。只關注其中一個面向就像做蛋糕卻忘了放麵粉。

Extracting Architecture Characteristics from Requirements#

有些架構特性直接來自需求文件中的明確陳述（例如預期使用者數量、規模需求）。但也有許多來自架構師的隱性領域知識。

例如：一個大學選課系統，假設有 1,000 名學生和 10 小時的選課時間。架構師應該假設學生會平均分散選課嗎？還是根據大學生的習性，預期全部 1,000 人在最後 10 分鐘才湧入？這類細節很少出現在需求文件中，但會直接影響設計決策。

Architecture Katas#

Architecture kata 是由 Ted Neward 發明的練習方法，源自日本武術中的「型」（kata）概念。每個 kata 包含：

• Description — 系統要解決的領域問題
• Users — 預期的使用者數量與類型
• Requirements — 領域層級的需求
• Additional context — 未明確寫入需求、但源自領域隱性知識的重要考量

Case Study: Silicon Sandwiches#

一家全國性三明治連鎖店想在現有電話訂餐服務之外，增加線上訂餐功能。

使用者：數千人，未來可能達到數百萬

需求：

• 使用者下單後取得取餐時間與路線（需整合外部地圖服務，含交通資訊）
• 若提供外送服務，需派遣司機送餐
• 行動裝置可存取性
• 提供全國性每日促銷活動
• 提供地方性每日促銷活動
• 接受線上、現場或貨到付款

額外背景：

• 三明治店是加盟制，各有不同老闆
• 母公司近期計畫拓展海外市場
• 企業目標是雇用低成本勞工以最大化利潤

Explicit Characteristics 分析#

架構師應檢視每項需求，判斷是否衍生出架構特性：

• 使用者數量（數千到數百萬）→ Scalability 是首要架構特性。注意需求並未直接要求 scalability，而是以預期使用者數表達

• 三明治店的流量模式（用餐時段尖峰）→ Elasticity，處理突發流量的能力。Scalability 與 elasticity 經常被混為一談，但約束條件不同：scalability 是持續增長的曲線，elasticity 是突發尖峰的波形

  

• 整合外部地圖服務 → 可能影響 reliability（第三方服務故障時的處理），但也要避免過度指定

• 行動裝置可存取性 → 主要影響設計（建議 mobile-optimized web app），架構師可定義 page load time 等 performance 特性

• 全國/地方促銷 → 暗示 customizability，可考慮 microkernel 架構或 Template Method 設計模式

• 線上付款 → 隱含 security，但不需超出一般隱式安全需求

• 加盟制 → 可能帶來成本限制，架構師應評估 feasibility

• 海外擴張 → 意味著 internationalization (i18n) 需求

• 低成本勞工 → 暗示 usability 的重要性，但更偏向設計而非架構

• Performance → 沒有人想從效能很差的三明治店訂餐，尤其在尖峰時段。需搭配 scalability 數據一起定義

Implicit Characteristics 分析#

• Availability — 確保使用者隨時可存取三明治網站
• Reliability — 確保互動過程中網站持續運作，不會斷線導致使用者需重新登入
• Security — 所有系統的隱式需求。在此案例中，架構師可假設付款由第三方處理，因此不需為安全性做特殊結構設計
• Customizability — 領域中多處需要客製行為（食譜、地方促銷、路線指引等可被在地覆寫），當問題領域的某個部分依賴客製結構來支持時，它就從設計層面上升為架構特性

架構中沒有「正確答案」，只有「昂貴的錯誤答案」（There are no wrong answers in architecture, only expensive ones）。架構師不需要過度糾結於找到完美的架構特性組合——開發者可以用多種方式實現功能。但正確辨識重要的結構性元素，有助於找到更簡潔優雅的設計。

精簡架構特性#

辨識出架構特性後，架構師還必須進行優先排序與精簡。一個實用的練習是：嘗試找出最不重要的那個特性，如果必須去掉一個，會是哪個？

以 Silicon Sandwiches 為例：

• Customizability 可以從架構特性中移除，改在應用程式設計層面實現
• Performance 在 operational 類特性中可能是最不關鍵的——不是要做出效能很差的應用，而是不需要將 performance 的優先順序置於 scalability 或 availability 之上

Design Versus Architecture and Trade-Offs#

以 customizability 為例，架構師面臨一個選擇：用架構手段（如 microkernel 風格）還是設計手段（如 Template Method 模式）來實現？

考量因素包括：

• 是否有其他理由（如 performance、coupling）不採用某種架構風格？
• 在不同設計方案中，支持所有架構特性的成本差異？
• 各方案在 trade-off 上的表現？

架構決策不應由架構師獨自做出（這會導致 Ivory Tower Architect 反模式）。架構師應與開發者、專案經理、營運團隊及其他共同建構者協作。在 Silicon Sandwiches 案例中，架構師、技術主管、開發者與領域分析師都應一起討論如何實現 customizability。