架構選擇與適配性檢查 是做什麼的？
將目標轉譯為可觀察的行為
識別參與者、關鍵工作流程、資料所有權和限制條件。將「可擴展」、「安全」和「可維護」轉化為場景：刺激 → 環境 → 反應 → 衡量。對能夠實質決定設計的少數特性進行排序。區分強制性限制與偏好選項。
程序
- 與利害關係人共同定義品質場景和驗收門檻。說明工作負載、故障和團隊假設。使用選擇指南。
- 識別每個屬性必須成立的範疇：元件、部署、工作流程或整個系統。不同的部分可能需要不同的風格。
- 比較一小組可行的風格與這些場景，包括模組化單一部署。解釋支援每一項所宣稱優點的機制。
- 檢查耦合度：原始碼依賴、執行期呼叫、共享資料和協調變更。靜態模組獨立性並不能證明執行期故障隔離。
- 選擇最簡單可行的風格，並記錄ADR、其後果以及重新評估的觸發條件。將可逆的實作細節與成本高昂的結構性承諾分開。
- 將關鍵決策轉化為適配性檢查：禁止的依賴、合約相容性、延遲預算、恢復時間和租戶隔離。使用適配性檢查。
- 在觀察到的負載和變更模式下重新評估。通過的依賴規則只是一個特性的證據，而非整體架構品質。
審查問題
- 插件邊界是否能滿足實際的可擴展性需求，而不會讓每個插件都可以不受限制地存取核心？
- 事件是否需要持久化發布、模式相容性、去重和延遲監控？這些成本是否已包含在事件驅動的提案中？
- 單獨部署是否能改善某個測量到的瓶頸或發布限制？
- 提議的團隊是否能運作所產生的部署和故障複雜度？
- 當資料所有權分開時，哪個不變量會變得難以維持？
輸出
回傳品質場景、候選機制/取捨、選擇的結構、所有權/依賴關係圖、ADR、適配性檢查以及未解決的假設。
範圍與參考
部分涵蓋範圍與《軟體架構基礎》（第2版，Richards和Ford）一致。作者資料、公開的作者訪談記錄、出版商內容以及架構測試文件支撐了這份原始指南。請參閱來源。沒有哪一種風格是普遍適用的成熟階段。