演化架構與緊急設計：架構與設計的定義、關注點與演進路線圖

「演化架構」與「緊急設計」的核心在於將重要決策推遲至最後負責時刻。系列首篇建立共同語言：定義架構與設計、釐清演化與緊急的差異、剖析技術債務與複雜度本質、警惕過度一般性，為後續實戰奠基。

架構的多維定義

• 應用架構：框架級架構（Spring、Hibernate 等技術棧選型）+ 邏輯架構（MVC、MVP 等關注點分離模式）。
• 企業架構：城市規劃視角，統籌跨系統資源（網路、安全、資料一致性），SOA 模糊了兩者邊界。
• 經典定義對比：
  • RUP/IEEE：最高層級系統概念，重要組件組織與介面。
  • Ralph Johnson：專家共識——系統如何分組件、組件如何互動。
  • Martin Fowler：「架構是重要的事物，無論它是什麼。」 強調語境相關性。
  • 實戰金句：「以後很難更改的內容。」 直接呼應演化架構「延遲決策」核心。

架構師角色辨析：Architectus Reloadus（唯圖不碼）vs Architectus Oryzus（深入代碼、促成共識），後者為演化架構關鍵推手。

設計的光譜：BDUF ↔ Cowboy Hacking

設計涵蓋模式、重構、框架選型等日常決策。圖譜左端是大量預先設計（BDUF），右端是無設計硬幹，敏捷實踐在中間動態平衡——隨著開發演進設計，而非一成不變。

三大全局關注點

1. 技術債務：本金與利息

為趕工期採取權宜之計 = 借用未來時間。新功能成本 = 內在複雜度（本金）+ 債務利息（修補舊代碼）。圖示清晰展示：低債務系統新功能成本線性增長，高債務系統指數級爆炸。

2. 本質 vs 偶發複雜度

• 本質複雜度：業務固有（如工會協議的狩獵季休假規則）。
• 偶發複雜度：技術引入（如 EJB 1/2 時代的樣板代碼、字段級安全過度設計、違反 DRY 的複製貼上、不可逆決策）。

三大偶發複雜度根源：時間壓力妥協、複製貼上、不可逆決策。對策：最後負責時刻決策、消除複製、保持選項開放。

3. 過度一般性：YAGNI 原則

Java 生態易陷入「為擴展而擴展」陷阱。一般性增加熵，讓每次變更更複雜。鐵律：You Ain't Gonna Need It——只實現當前需求，未來再擴展。把握擴展性與過度設計的微妙界線，是架構師核心功力。

系列路線圖

本文鋪墊概念地基，後續每篇深入一到兩個具體主題並附代碼實戰：

1. 測試驅動設計（上/下）——緊急設計核心實踐
2. 組合方法與 SLAP——代碼結構導航模式
3. 重構識別緊急設計——耦合、複製、指標驅動重構
4. SOA 專題——企業架構邊界模糊地帶
5. 更多演化架構實戰模式……

目標：構建在變化中穩健演進的軟件系統。