什麼是架構 (What Is Architecture?)#

架構師不是坐在象牙塔裡畫圖的人，他們必須也是寫程式的人。 架構是建置者賦予系統的樣貌（Shape）。這個樣貌的形式是由元件的劃分、排列與溝通方式所決定的。

但這個樣貌的目的是什麼？ 不是為了讓系統運作（那是基本要求），而是為了支援系統的生命週期。

架構的終極目標： 「最小化系統在生命週期中的建置與維護成本，並最大化工程師的生產力。」

一、架構對生命週期的四大影響#

好的架構必須在以下四個面向支撐系統：

1. 開發 (Development)#

• 難題： 如果一個系統由五個團隊同時開發，卻沒有良好的元件劃分，開發過程將變成災難（互相踩腳）。
• 解法： 架構必須將系統劃分為定義明確、介面穩定的元件，讓團隊能並行開發。

2. 部署 (Deployment)#

• 目標： 單一動作（Single Action）。好的架構應該讓人下載後執行一個指令就能跑起來。
• 反例： 如果部署需要設定十幾個微服務的 config、建立複雜的資料夾結構、還得按特定順序啟動，這就是失敗的架構（通常是因為微服務切分過細）。

3. 運行 (Operation)#

• 影響較小： 架構對運行的影響其實不如開發和維護大（因為運作效率通常可靠升級硬體解決）。
• 價值： 架構在運行層面的價值在於溝通。好的架構能清楚揭示系統的使用者案例（Use Cases） 、特性與行為。這就是所謂的「尖叫架構（Screaming Architecture）」——看一眼架構圖就知道系統在做什麼業務。

4. 維護 (Maintenance)#

• 成本之王： 維護是所有環節中成本最高的。
• 主要成本：
  • 探礦（Spelunking）： 為了修一個 Bug 或加一個功能，工程師得花數小時在程式碼深處挖掘，試圖理解現有邏輯的代價。
  • 風險： 修改這裡卻意外弄壞那裡的風險。
• 解法： 好架構透過穩定的介面隔離元件，大幅降低探礦時間與修改風險。

二、保持選項開放 (Keeping Options Open)#

這章最核心的觀念在於重新定義「軟體（Software）」的本質。 軟體之所以被稱為**「軟」**，是因為它原本就該是容易被改變的。

1. 策略 vs. 細節#

為了讓系統保持柔軟，架構師必須區分兩類元素：

• 策略 (Policy)： 所有的業務規則與程序。這是系統的真正價值所在。
• 細節 (Details)： 那些讓人類、其他系統或資料庫能與策略互動的機制。
  • 資料庫是細節。
  • Web 框架是細節。
  • 伺服器硬體是細節。

2. 延遲決定 (Deferring Decisions)#

架構師的職責不是做出決定，而是讓決定可以「盡量晚點做」。

• 好的架構師： 會設計出一種結構，讓你在專案開發了一年後，還不需要決定要用 MySQL 還是 Oracle，甚至不需要決定要用 Web 還是 Console 介面。
• 為什麼？ 因為你推遲決定的時間越晚，你擁有的資訊就越多，做出的決定就越正確。

總結： 一個好的架構會強調策略（Policy），並讓**細節（Details）**脫鉤。 它讓你有能力對老闆說：「我們還不需要決定要用什麼資料庫，我們可以先把核心業務邏輯寫好並測試完畢。」 讓選項保持開放，就是架構的力量。