架構特性與權衡#

複雜度管理告訴我們架構是為了解決複雜度，但「複雜度」本身過於籠統。要把它落到可設計、可驗證的層面，需要一套更精確的語言：架構特性（Architecture Characteristics），也就是業界常說的「非功能需求」或「品質屬性（Quality Attributes）」。本章釐清這些名詞的差異，說明如何辨識真正該關注的特性，以及為什麼這些特性之間必然要取捨。

三個容易混淆的名詞#

這三者大量重疊，但「架構特性」這個說法最貼近架構師的工作：它強調的是那些一旦選定就會塑造系統結構的面向。並非所有非功能需求都是架構特性——有些可以靠後期調校解決，不影響結構。

把焦點從「非功能需求」轉成「架構特性」，是把消極的清單（「不要慢、不要當機」）翻譯成積極的設計目標（「為高吞吐而設計」），這樣才能驅動結構決策。

三判準：什麼才算架構特性#

一個面向要被列為架構特性，需同時滿足三個條件。任一不滿足，就不該佔用架構師的設計預算。

第三個判準最常被忽略。架構師傾向把所有特性都拉到「重要」，導致過度設計。請參考簡單原則：能不列就不列，每多一個特性都會增加結構複雜度。

架構特性的三大分類#

把架構特性歸類，有助於在需求訪談時系統性地「掃描」，避免遺漏。

操作型（Operational）#

與系統運行時的行為有關，多半可量化、可監控。

這些與高效能、高可用、可擴展性章節高度相關。

結構型（Structural）#

與程式碼的內部品質與組織方式有關，多半難以量化。

跨領域（Cross-cutting）#

橫跨整個系統、不易歸入前兩類，卻往往攸關存亡。

隱式特性最易漏#

架構特性可分為**顯式（Explicit）與隱式（Implicit）**兩種：

• 顯式特性：寫在需求文件裡，業主明確提出（例如「尖峰每秒一萬筆交易」）。
• 隱式特性：沒人寫下來，卻被預設一定要有（例如安全性、資料一致性、合理的可用性）。

災難多半來自隱式特性。沒人會在需求裡寫「請不要洩漏使用者密碼」，但漏掉它後果嚴重。架構師的價值之一，正是主動把隱式特性挖出來、攤在桌面上討論。

挖掘隱式特性的提問清單：

• 這個產業有沒有監管或合規要求？
• 競品都具備、使用者預期一定有的非功能面向是什麼？
• 哪些「不出事就沒人提，一出事就上新聞」的面向（安全、隱私、資料完整）？

特性間必然取捨：不可全要#

架構特性之間存在相互拉扯，幾乎不可能同時最大化。試圖「全都要」會得到一個處處平庸的系統。

flowchart LR
    P[效能] -.衝突.- S[可擴展性]
    S -.衝突.- C[一致性]
    SEC[安全性] -.拖慢.- P
    SIMP[簡單性] -.犧牲.- EXT[可擴充性]

    style P fill:#e3f2fd
    style S fill:#e8f5e9
    style C fill:#fff3e0
    style SEC fill:#ffebee
    style SIMP fill:#f3e5f5
    style EXT fill:#ede7f6

典型的取捨關係：

架構師的工作不是「達成所有特性」，而是在衝突的特性間做出明確、可被追溯的取捨。把取捨的理由記錄下來，正是 ADR 存在的理由。

設計時建議只挑出 3 ～ 7 個 真正關鍵的「驅動特性」，其餘列為「次要」，明確告知會被犧牲。

本章小結#

每次架構評審，先問三題：我們在優化哪些特性？我們明確放棄了哪些特性？這些取捨記錄在哪？答不出來，代表特性還沒被想清楚。