Architecture Decision RecordAWS 架構決策記錄流程
架構決策記錄（ADR）係一份文件，描述團隊就佢哋計劃建構嘅軟件架構入面一個重要環節所作出嘅選擇。每份 ADR 都會講明該項架構決策、佢嘅背景同埋後果。ADR 有狀態，所以會跟住一個生命週期。想睇 ADR 嘅例子，請參閱附錄。
ADR 流程會產出一批架構決策記錄，呢批記錄就組成決策日誌。決策日誌提供項目背景，以及詳細嘅實施同設計資料。項目成員會速讀每份 ADR 嘅標題，去了解項目背景嘅概況；亦會細讀 ADR，深入了解項目嘅實施同設計選擇。
團隊一旦接納某份 ADR，佢就變成不可更改。如果有新嘅見解需要作出另一個決策，團隊就會提出新嘅 ADR。新 ADR 獲接納之後，就會取代之前嗰份 ADR。
ADR 流程嘅範圍
項目成員應該為每項影響軟件項目或產品、而且對架構有重大意義嘅決策建立 ADR，包括以下各項（Richards 同 Ford 2020）：
結構（例如微服務呢類模式）
非功能性需求（保安、高可用性同容錯能力）
依賴關係（組件之間嘅耦合）
介面（API 同已公佈嘅合約）
建構技術（程式庫、框架、工具同流程）
功能性同非功能性需求，係 ADR 流程最常見嘅輸入。
ADR 嘅內容
團隊發現需要一份 ADR 嗰陣，會由一位團隊成員按照全項目通用嘅範本開始撰寫。（範本例子請睇 ADR 嘅 GitHub 組織。）範本令建立 ADR 變得簡單，亦確保 ADR 收錄所有相關資料。每份 ADR 至少應該界定決策嘅背景、決策本身，以及該決策對項目同埋佢可交付成果嘅後果。（呢啲部分嘅例子請參閱附錄。）ADR 結構其中一個最強大嘅地方，係佢聚焦於做決策嘅原因，而唔係團隊點樣實施。明白團隊點解會做呢個決策，其他團隊成員就更易接受；咁亦可以避免冇參與決策過程嘅其他架構師日後推翻該決策。
ADR 採用流程
每位團隊成員都可以建立 ADR，不過團隊應該訂立 ADR 嘅擁有權定義。每位擔任 ADR 擁有者嘅作者，應該積極維護同傳達 ADR 嘅內容。為咗釐清擁有權，本指南喺以下章節將 ADR 作者稱為 ADR 擁有者。其他團隊成員隨時都可以為 ADR 出力。如果 ADR 喺團隊接納之前內容有變，擁有者應該批准呢啲更改。
團隊確定咗一項架構決策同佢嘅擁有者之後，ADR 擁有者喺流程開始時會以建議中（Proposed）狀態提供 ADR。處於建議中狀態嘅 ADR 已經可以進行審閱。
之後 ADR 擁有者會啟動 ADR 嘅審閱流程。審閱流程嘅目標，係決定團隊接納 ADR、認為需要修改，定係否決 ADR。項目團隊（包括擁有者）會審閱 ADR。審閱會議應該一開始就預留一段專門時間嚟閱讀 ADR，平均 10 至 15 分鐘就夠。喺呢段時間，每位團隊成員會閱讀文件，並且加入意見同問題，標示唔清楚嘅地方。審閱階段完咗之後，ADR 擁有者會逐項讀出並同團隊討論每個意見。
如果團隊發現有跟進事項可以改善 ADR，ADR 嘅狀態會維持建議中。ADR 擁有者負責擬定跟進行動，並且同團隊合作，為每項行動指派負責人。每位團隊成員都可以參與並完成跟進事項。重新安排審閱流程係 ADR 擁有者嘅責任。
團隊亦可以決定否決 ADR。呢種情況下，ADR 擁有者會加上否決嘅原因，避免日後再討論同一個課題，並將 ADR 狀態改為已否決（Rejected）。
如果團隊批准 ADR，擁有者會加上時間戳記、版本同持份者名單，然後將狀態更新為已接納（Accepted）。
ADR 同佢哋組成嘅決策日誌，代表團隊所作嘅決策，並且提供所有決策嘅歷史。團隊盡可能喺程式碼審閱同架構審閱嗰陣用 ADR 作參考。除咗進行程式碼審閱、設計工作同實施工作之外，團隊成員就產品嘅策略性決策亦應該參考 ADR。
按照良好做法，每項軟件更改都應該經過同儕審閱，而且至少需要一個批准。程式碼審閱期間，審閱者可能會發現有更改違反一份或者多份 ADR。呢種情況下，審閱者會要求程式碼更改嘅作者更新程式碼，並分享 ADR 嘅連結。作者更新程式碼之後，同儕審閱者批准，就會合併入主程式碼庫。
ADR 審閱流程
團隊接納或者否決 ADR 之後，應該將佢當作不可更改嘅文件。如果要更改現有嘅 ADR，就需要建立新 ADR、為新 ADR 設立審閱流程，並且批准該 ADR。新 ADR 獲團隊批准之後，擁有者應該將舊 ADR 嘅狀態改為已取代（Superseded）。