什麼是 Architecture Characteristics#
軟體架構師的一項關鍵職責，是定義、發掘並分析所有與領域功能（domain functionality）無直接關聯、但系統必須具備的特性，也就是所謂的 architecture characteristics（架構特性）。
業界對這些特性有許多稱呼，包括 nonfunctional requirements（非功能需求）與 quality attributes（品質屬性）。作者偏好使用 architecture characteristics，因為它強調這些特性對架構成功的關鍵性，不會像「nonfunctional」那樣在語言上自我貶低。
架構特性的三個判斷標準#
一個特性要被視為 architecture characteristic，必須同時滿足以下三個條件：
- Specifies a nondomain design consideration — 不屬於領域需求本身，而是關於「如何實現」的設計考量（例如 performance、security）
- Influences some structural aspect of the design — 會影響架構的結構性決策，需要特殊的結構支持才能實現
- Is critical or important to application success — 對應用程式的成功至關重要
Figure 4.1: A software solution consists of both domain requirements and architectural characteristics
應用程式理論上可以支援大量的 architecture characteristics，但不應該這麼做。每多支援一個特性就會增加設計複雜度。架構師的關鍵工作是選擇最少且必要的特性，而非追求最多。
Explicit vs. Implicit Characteristics#
架構特性可進一步區分為：
- Explicit characteristics（顯式特性）— 明確出現在需求文件或規格說明中
- Implicit characteristics（隱式特性）— 雖未出現在需求中，但對專案成功不可或缺。例如 availability、reliability、security 幾乎是所有應用程式的隱式需求，架構師必須依據領域知識主動辨識
Architectural Characteristics（部分列表）#
架構特性涵蓋廣泛且沒有通用標準，每個組織可能有自己的定義與詮釋。作者將常見的架構特性分為三大類。
Operational Architecture Characteristics#
涵蓋系統運行時的能力，與 operations 和 DevOps 高度重疊。
| 特性 | 說明 |
|---|---|
| Availability | 系統需要多長時間保持可用（例如 24/7），以及故障時快速恢復的能力 |
| Continuity | 災難復原（disaster recovery）能力 |
| Performance | 壓力測試、峰值分析、回應時間等，有時需要數月獨立評估 |
| Recoverability | 災難發生時系統需多快恢復上線，影響備份策略與硬體冗餘需求 |
| Reliability/Safety | 系統是否需要 fail-safe？故障是否會影響人命或造成巨額損失？ |
| Robustness | 在網路中斷、電力故障、硬體故障等邊界條件下的錯誤處理能力 |
| Scalability | 隨使用者或請求數增加，系統仍能正常運作的能力 |
Structural Architecture Characteristics#
關注程式碼結構與內部品質，架構師通常對此負有全部或共同責任。
| 特性 | 說明 |
|---|---|
| Configurability | 終端使用者透過介面輕鬆更改軟體設定的能力 |
| Extensibility | 插入新功能的容易程度 |
| Installability | 在所有必要平台上安裝系統的容易程度 |
| Leverageability/Reuse | 跨多個產品共用元件的能力 |
| Localization | 支援多語言、多位元組字元、度量衡與貨幣等 |
| Maintainability | 系統變更與增強的容易程度 |
| Portability | 系統是否需要在多個平台上運行 |
| Supportability | 應用程式需要的技術支援層級（logging、debugging 設施等） |
| Upgradeability | 從舊版本升級到新版本的容易程度 |
Cross-Cutting Architecture Characteristics#
不易歸入單一類別，但仍構成重要的設計限制與考量。
| 特性 | 說明 |
|---|---|
| Accessibility | 讓所有使用者（包含身障者）都能使用系統 |
| Archivability | 資料是否需要在一段時間後歸檔或刪除 |
| Authentication | 驗證使用者身份的安全需求 |
| Authorization | 確保使用者只能存取被授權的功能 |
| Legal | 系統運行所在地的法規限制（如 GDPR、Sarbanes-Oxley 等） |
| Privacy | 隱藏內部人員（包含 DBA 與網路架構師）對交易資料的存取能力 |
| Security | 資料加密、網路通訊加密、遠端存取認證等需求 |
| Supportability | 除錯與診斷所需的 logging 與技術支援設施 |
| Usability/Achievability | 使用者需要多少訓練才能達成目標，可用性需求應被視為與其他架構議題同等重要 |
任何架構特性清單都必然是不完整的。每個軟體系統都可能因其獨特因素而產生新的架構特性。書中提到一個有趣的例子：Italy-ility — 一個組織因曾經歷與義大利分支機構失聯的慘痛經驗，從此要求所有架構都必須具備這個自創的特性，本質上是 availability、recoverability 與 resilience 的獨特組合。
ISO 標準定義#
國際標準化組織（ISO）也發布了一份按能力分類的架構特性清單，包含以下類別：
- Performance efficiency — 資源使用效率，包含 time behavior、resource utilization、capacity
- Compatibility — 與其他系統共存與交換資訊的能力，包含 coexistence 與 interoperability
- Usability — 有效且滿意地使用系統的能力，包含 learnability、user error protection、accessibility
- Reliability — 在指定條件下持續運作的能力，包含 maturity、availability、fault tolerance、recoverability
- Security — 保護資訊與資料的能力，包含 confidentiality、integrity、nonrepudiation、accountability、authenticity
- Maintainability — 修改軟體的效率，包含 modularity、reusability、analyzability、modifiability、testability
- Portability — 在不同環境間轉移的能力，包含 adaptability、installability、replaceability
Trade-Offs and Least Worst Architecture#
應用程式只能支援有限數量的架構特性，原因有二：
- 每個特性都需要設計投入與結構支持
- 架構特性之間往往互相影響 — 例如提升 security 幾乎必然會降低 performance（需要更多加密、間接層、秘密隱藏等操作）
作者用學習駕駛直升機的比喻來說明：直升機的每隻手和每隻腳各控制一個操縱桿，改變一個就會影響其他所有操控。選擇架構特性也是如此——每多支持一個特性，就可能使整體設計變得更複雜。
永遠不要追求「最佳」架構，而是追求「最不差」的架構。 過多的架構特性會導致通用型解決方案，試圖解決所有問題，但這樣的架構因過度複雜而幾乎不可能成功。
架構師應致力於讓架構設計盡可能具有迭代性（iterative）。如果架構可以輕鬆變更，就不需要在第一次就找到完美答案。Agile 開發中迭代的價值，在架構設計中同樣適用。