軟件架構師：
應明確提出假設或先決條件，從而防止隱性假設
知道隱性假設可能會導致利益相關方之間的潛在誤解

---

1. 應明確提出假設或先決條件，防止隱性假設

為什么重要？

• 隱性假設是架構風險的溫床
  例如：假設“所有服務都能在100ms內響應”，若未顯式聲明，可能導致：
  • 調用方未設計超時機制 → 級聯故障
  • 運維團隊未配置監控告警 → 故障無法快速發現
• 技術債務的源頭
  如默認團隊熟悉某框架（實際新人占比高），代碼質量會因學習成本陡降。

實踐方法

場景	顯式化方法	案例
技術約束	在架構決策記錄（ADR）中聲明	“服務通信必須使用gRPC，因二進制協議性能比JSON高50%”
資源假設	在部署規范中標注	“數據庫需SSD存儲，IOPS≥5000”
第三方依賴	在上下文圖中標記SLA	“支付網關可用性99.9%，超時需重試2次”
團隊能力邊界	在項目啟動文檔中說明	“前端團隊需掌握Vue3，否則培訓周期增加2周”

---

2. 知道隱性假設可能導致利益相關方誤解

典型誤解場景

破解策略

1. 術語統一詞典
   創建《架構術語表》，例如：

   • “彈性伸縮”：指系統負載＞80%時自動擴容，響應延遲＜10s
   • “數據一致性”：指最終一致性，最大延遲60秒

2. 多視角驗證

   • 用可執行原型驗證性能假設（如模擬10K并發）
   • 通過架構工作坊讓開發/測試/運維共同評審假設

3. 假設跟蹤矩陣

   假設內容	影響范圍	驗證方式	失效應對方案
   “CDN延遲≤50ms”	全局用戶體驗	壓測+監控	啟用備用CDN供應商
   “消息隊列無丟消息”	訂單交易	混沌工程測試	補單機制+告警

---

架構師的核心行動清單

1. 挖掘隱性假設

   • 通過“5 Whys分析法”追問設計決策根源
     例：為什么選Redis？→ 因需要低延遲 → 延遲要求多少？→ ≤2ms → 是否驗證過網絡拓撲？

2. 可視化假設

   • 在C4模型或架構圖中用紅色注解標出高風險假設

3. 建立反饋環

   • 在CI/CD流水線中加入假設校驗測試（如性能閾值檢測）

關鍵洞察：優秀的架構師不是避免假設（這不可能），而是像科學家一樣顯式管理假設——將其轉化為可驗證、可追溯、可應對風險的公開約束條件。這直接決定了架構的適應性和系統可靠性。