本期轉向架構層面，探討四大實戰議題：架構與設計的本質區別、企業級架構師的政治生存、Build vs Buy 決策框架、分布式系統端點類型控制策略。
一、架構 vs 設計：Martin Fowler 的經典定義
「架構是完成後很難更改的東西。所以這種東西應該盡可能越少越好。」
- 架構：Web 框架選型、資料庫技術、部署拓撲、安全體系、核心中間件——變更成本極高，牽一髮動全身
- 設計：類別結構、設計模式應用、演算法選擇、API 簽名——在架構約束內可輕微調整
識別陷阱：框架的「毒販模式」
框架誘導你繼承其基類（如 Struts `ActionForm`），導致領域模型耦合框架：
後果：想在 Swing 中復用 `ScheduleItem`？必須把整個 Struts 拖過去，或重寫模型。
解法：組合替代繼承——領域模型實現接口，框架適配器持有領域模型實例：
鐵律：讓框架認識你，不要你認識框架。領域模型零框架依賴，適配層吸收框架 API。
二、架構師的政治生存指南
- 最高技術職位 = 最大替罪羊：失敗歸你，成功歸團隊
- 溝通 > 技術：《Peopleware》真理：「總是存在人的問題」
- 決策須可辯護：記錄決策理由（ADR），面對邏輯不通但政治可行的干擾時有據可查
- 拒絕「技術傲慢」：不因個人偏好拒絕成熟方案，評估標準公開透明
三、Build vs Buy：戰略 vs 經費決策樹
核心判斷：業務流程是戰略資產還是經費成本？
| 維度 | 戰略流程（自建） | 經費流程（採購 COTS） |
|---|
| 競爭優勢 |
核心差異化能力 |
標準化、無差異化 |
| 定制深度 |
深度定制、持續演進 |
配置為主、輕度擴展 |
| 廠商鎖定風險 |
可控 |
高（深度定制即鎖定） |
| 典型例子 |
核心交易、風控建模、智能推薦 |
人資薪資、財務報表、郵件系統 |
決策三關鍵節點
- 戰略/經費分類：戰略 → Build；經費 → 進入節點 2
- 開箱即用度：COTS 能 80%+ 無定制滿足 → Buy；否則 → 節點 3
- 可擴展 vs 可定制：
- 可擴展：定義良好的擴展點（API、事件、插件），升級不破壞 → 可 Buy
- 可定制：改源碼、改配置檔、掛鉤子，升級痛苦 → 傾向 Build
案例：金融服務公司的招聘系統
招聘被視為戰略優勢（招最聰明的人、流程最嚴謹）。顧問建議自建 HR 系統，雖耗時長，但構建差異化平台。若買 COTS，競爭對手買同套系統 → 無差異。
四、SOA 端點類型控制：寬鬆類型與版本演進
分布式系統端點（兩系統通信門戶）的類型策略決定演進靈活度。
強類型陷阱：RPC + WSDL
- WSDL 定義參數類型、順序、結構 → 雙方強耦合
- 單方變更參數需同步升級另一方，否則通信失效
- 變通方案：`addOrder` → `addOrder2` → `addOrder3`... 端點爆炸、代碼重複
寬鬆類型方案：文檔驅動 + Factory/Strategy 解析
核心機制
- 端點統一接收文檔（XML/JSON），不預設結構
- 文檔含 `version`/`type` 標識，或透過內容推斷
- Factory 根據標識實例化對應 Strategy 解析器
- Strategy 負責：驗證 → 反序列化 → 轉換為內部領域對象
- 業務邏輯僅見領域對象，零端點版本感知
收益
- 單一端點支援多版本消費者，各按節奏升級
- 職責分離：端點只管「收文檔、產領域對象」，不混雜業務邏輯
- 可用 SOAP（文檔字面風格）或 REST 實現，REST 更自然
- 演化架構精髓：奠定基礎，支援無摩擦、無損害的變革
工具現狀與建議
目前主流框架（Spring WS、CXF、WCF）對寬鬆類型端點支援有限，需自行實現 Factory/Strategy 層。但前期投入換取長期演進自由，ROI 極高。
下一期將聚焦：緊急設計實戰案例——指標驅動發現 Struts 代碼庫中的參數處理慣用模式，從結構重複識別到元程式重構全過程。
