什麼是架構？
牛津詞典定義：計算機系統的設計與結構。架構師：負責規劃或創造想法、事件、局面的人。針對企業應用，架構可分四類：
- 業務架構：關注業務流程
- 應用架構：關注應用系統設計（本系列主題）
- 基礎架構：關注基礎技術
- 數據架構：關注數據存儲規劃
應用架構五大組成部分
- 目標與願景：系統面臨的問題域
- 評價指標：從哪些維度度量方案優劣
- 原則與方法論：解決問題的指導思想
- 技術架構：具體設計結構
- 組織因素：團隊如何參與協作
架構的目標與願景：問題從哪來？
外部：客戶業務與技術要求
內部：組織管理、項目管理、技術演進
非業務核心問題
- 系統目標：效能、穩定性
- 項目目標：開發成本、質量
- 項目過程：需求不確定性、團隊協作（開發管理）
架構的核心問題域分解
| 維度 | 業務層面 | 技術層面 |
|---|
| 縱向 | 邏輯抽象層次 | 技術主題（安全、事務、持久化...） |
| 橫向 | 模塊分解與集成 | 技術職責分解與集成 |
三大關鍵挑戰
- 領域化：傳統三/四層架構未解決業務模型建立、層間傳遞、模型關聯、服務邏輯耦合；分析模型到設計模型轉換斷層。
- 組件化：
- 內部管理：業務切分、進度控制、風險降低、財務分析、知識傳遞
- 銷售需求：All-in-one 不利銷售，組件化支援按需打包、降低集成風險
- 產品化：
- 定制化：行業無標準、產品面向通用、客戶差異導致需求差異 → 分支維護成本高
- 升級：數據遷移、舊版本兼容、依賴關聯、定制化衝突檢測
- 國際化：文本/佈局/時區/計量單位/多幣種
架構的應用問題
- 事務管理：並發控制錯誤、業務操作錯誤導致數據不一致
- 並發處理：業務場景差異大，需原則與框架支援
- 集成能力：異構環境（外部/內部/遺留）、多模式（文件/資料庫/消息）
架構的設計問題
分析設計（知識級）vs 開發實現（操作級）。傳統文檔與代碼割裂導致溝通困難、設計與實現不一致風險。需以代碼承載設計，框架約定落地。
架構評價指標三維度
| 維度 | 關鍵指標 |
|---|
| 財務 | 開發成本、維護成本（通常 3 倍開發成本）、效率、適應變化能力 |
| 技術 | 侵入性/可遷移性、重復性、擴展性、平穩性、抽象性/可視性、修改性/可測試性、診斷性、性能、可靠度、可用度 |
| 組織 | 角色參與度、人力資源匹配、流程匹配度、產出物銜接 |
原則與方法論
- 總原則：關注點隔離 — 高層設計劃分邏輯邊界，詳細設計單一職責（一個接口一個實現）
- 方法論：自上而下、由內而外 — 理論體系：OO/AOP、DDD、TDD
- 演化路徑：總結歸納型（工程師主流）vs 技術思辨型（大牛創新，如 GC、AOP）
