架構師不是坐在象牙塔裡畫圖，他們也寫程式。
架構是建置者賦予系統的樣貌（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） 脫鉤。 它讓你能對老闆說：「我們還不需決定要用什麼資料庫，可以先把核心業務邏輯寫好並測試完畢。」
讓選項保持開放，就是架構的力量。