穩健架構 (Robust Architecture)
產出最小的設計，使其保證能夠被解釋和挑戰。規則引導決策，而非驗證正確性。一個有用的架構能讓重要的事實變得明確，為規則提供一個權威性的歸屬，並且在發生故障或變更時仍能保持可理解性。
從後果開始
對於既有系統，在信任圖表或先前的提議之前，請檢查實際的進入點、呼叫者、狀態儲存和檢查點。對於新系統，請區分需求與假設；在選擇元件之前，先描述第一個真實的流程。
僅記錄會改變決策的約束條件：使用者和權威、運作量、延遲或資源預算、可用性、故障條件、復原和持久性需求、部署限制，以及團隊能夠運作的項目。當產品選擇會影響正確性時，請詢問缺失的產品選擇。在該選擇尚未解決時，繼續進行獨立、可逆轉的工作。
校準干預的級別：
- 模型/所有權缺口： 必要的事實、完整的操作或一致的權威缺失或分裂。在修補其讀取者之前，先解決該合約。
- 邊界缺陷： 存在一個適當的擁有者，但呼叫者繞過它，或其實施不完整。深化或使用該擁有者；跨越層級的缺陷本身並不需要一個新的架構。
- 產品缺口： 要求的行為尚未決定。呈現具體的後果和最小的選擇，而不是默默地選擇。
- 呈現/局部缺陷： 正確的底層事實需要局部呈現、解析或複製修正。應用正常的局部修正；在此停止架構工作流程。
一個大型檔案、重複的語法、遺失的模式名稱，或提議的套件，本身並非模型缺口的證據。
對於涉及存取受保護資源的設計或審查，如果已安裝 authorization 技能，請套用之。它擁有存取原則逐步審查的權責；當單獨使用此技能時，請保留以下的局部所有權和信任規則。
賦予事實和規則一個家
命名事實或不變量、其邏輯權威，以及允許修改的操作。權威可以是一個局部函數、檔案發佈者、程式庫句柄、處理程序或服務；它不必是伺服器或一個新的模組。
- 將規則放置在能夠對所有相關生產者執行它的位置。進入點適配器建立呼叫者信任、解析輸入、呼叫該擁有者並轉換結果。有用的早期檢查能改善回饋；權威性檢查能保護實際的效果。
- 明確地模型化誰擁有共享資料。遺失的父項或範圍值並非自動等同於全域權威。對讀取、序列化和效果應用參與者實際的政策，而不僅僅是可見的控制項。
- 分離目前的關係、不可變的發生事實和投影。儲存該功能真正需要的歷史或快照。目前的關係無法重建遺失的過去事實；誠實地標記不可知的遺留歷史。
- 賦予重試其操作身份。兩個相同的負載可能是不同的意圖。當重試的正確性至關重要時，在當前的權威下定義金鑰範圍、不匹配的重複使用、保留和重播。
- 為衍生規則和表示法提供一個單一的維護定義，所有消費者必須同意。保留受眾、群組、單位和時間意義之間有意的差異。當共享會創建人造依賴時，保持便宜的局部呈現重複。
- 明確指定的多寫入者或離線設計是有效的。命名衝突語義、協調和分割行為，而非假設總是能強制實施單一物理寫入者。
一個邊界的存在價值在於隱藏一個決策，並從呼叫者那裡移除知識。直接檢查這一點：在變更之後，哪個呼叫者不再知道規則、儲存佈局或順序？一個讓每個呼叫者都協調相同業務步驟的包裝器並沒有轉移所有權。
擁有完整的結果
追蹤一個意圖直到其重要的效果。陳述哪些部分必須保持一致、權威性的完成點，以及如果執行在該點之前或之後停止，使用者會收到什麼。
枚舉每個可觀察的發佈，包括快取和背景回呼。對於非同步工作，請識別一個結果所屬的操作、身份、版本和生命週期，並在每個相關的發佈邊界檢查適用性。一個延遲的視圖檢查無法保護先前的快取或儲存寫入。區分取消一個消費者和撤銷一個已提交的業務效果。
對於在一個權威內需要不可分割性的不變量，請使用實際的原子基元。當並行寫入者可能使先前的讀取失效時，在效果或等效的序列化中強制實施適用的範圍、狀態和版本。將機制匹配到可達的交錯；一個單執行緒的純轉換不需要資料庫風格的並行機制。
在網路、處理程序、檔案或非同步邊界，請閱讀 邊界檢查。選擇相關的分支：持久性效果、資源生命週期、即時工作，或狀態/歷史。一個局部事務並不會使外部效果具有原子性；一個未知的結果不一定就是失敗。在添加重試之前，定義復原和誠實的待定/部分結果。
對於可重複使用的 API，請明確說明輸入、輸出、拒絕、所有權和清理責任。保留有意義的錯誤/控制流區別。將診斷資訊放置在可以在不暴露受保護資料的情況下解釋失敗的位置；日誌不是復原機制，也不是授權/歷史資料庫。
選擇一個比例適當的結構
偏好現有的連貫模組和支援的平台機制。在一個新的小型應用程式中，幾個界限明確的函數或模組可能就足夠了。當具體需求需要獨立擴展、故障隔離、執行時期限制或組織所有權時，才考慮分離部署或引入基礎設施。在解釋重要的取捨時，尊重已被明確選擇的平台。
評估在一個可行的替代方案旁邊的最小變更。解釋在正確性、資源/運作成本和可逆性方面的重要差異。將每個設計決策保留在一個歸屬處；僅獨立提取穩定且有用的接縫。實體資料夾、套件和服務應遵循已被驗證的邊界，而不是提供證明。
在變更位置時，保持完整的不變量。遷移和版本更替必須考慮現有資料、舊/新寫入者、公開消費者和版本回退的相容性。移除一個欄位、API 或資源需要證據證明其義務和消費者已經終止。
嘗試反駁它
選擇一個能測試有爭議邊界的薄垂直切片。使用與該主張相關的真實儲存、檔案、通訊協定或資源接縫；僅隔離真正的外部依賴。對於一個尚無實作的早期設計，請指定一個有區辨力的實驗，並讓其結果保持未知。
使用相關的失敗來挑戰不變量：錯誤的權威、過時的狀態、重複或重新排序的工作、在完成邊界處的崩潰、取消、遺失/模糊的歷史，以及實際的負載或時間限制。在它們能區分規則時，使用明確的誘餌和受控制的交錯或時鐘。一個測試應該在該規則被移除時失敗，而不僅僅是計算模擬的呼叫次數或識別選定的名稱。
檢查安全性 和 進展：一個有效的操作最終如何完成或給出誠實的拒絕；待定的工作如何復原；記憶體、佇列、連線和延遲如何維持在邊界內。從運作範圍中選擇這些檢查，而不是演練每一個理論上的失敗。
在聲稱某個流程有效時，觀察安裝/使用者或公開程式庫的流程。單元斷言、圖表、綠色重試、基準猜測和合成測試夾具僅能建立它們自己測試的邊界。分離測量結果、來源發現、假設、缺失的決策和未執行的證明。
交付可審查的決策
根據決策的規模調整輸出。對於一個實質性的設計，請提供：
- 具體的流程、約束條件和重要的未知事項。
- 不變量、已命名的權威以及受影響的生產者/消費者。
- 狀態/歷史、信任、完成和失敗邊界，並附有足以追蹤成功和失敗的合約。
- 選擇的小型結構、一個相關的替代方案，以及為什麼該取捨是合適的。
- 第一個切片，帶有可觀察的驗收、復原和演進/版本更替檢查。
- 哪些已準備就緒，哪些需要產品決策或證明，以及哪些已經過實際驗證。
僅在圖表能使邊界更清晰時，才使用小型圖表。對於局部修正，跳過空的範本章節。保留使用者的範圍：一個設計/審查請求會產生一個決策，而非實施、遷移、部署、發佈或更改線上資料的許可。
在採用或評估此技能時，請參閱 評估協議。主要背景列在 基礎 中；它提供推理的依據，而非驗證個別設計。
此技能的中文 (zh-TW) 版本翻譯由 AI 生成。