架構決策記錄 (Architecture Decision Record)
ADR 的存在是為了讓十八個月後，沒有人會在不知道當初為何做出決定而重新提起一個已解決的問題，也為了在情境改變時，能夠有意識地重新審視該決定。
存放位置
docs/adr/NNNN-short-title.md，依序編號。檢查目錄以取得下一個編號和團隊範本；如果有的話，請遵循該範本。
範本
# NNNN. <以決策形式呈現的標題：「為訂單服務使用 Aurora PostgreSQL」>
日期：YYYY-MM-DD
狀態：已提議 | 已接受 | 已被 NNNN 取代 | 已棄用
決策者：<姓名或團隊>
## 背景
<哪些力量在運作：需求、限制、當前的痛點、截止日期、合規性、
團隊技能、成本範圍。兩到四段。事實，而非意見。>
## 決策
<一兩句話，現在式：「我們將……」>
## 考慮選項
### 選項 A：<名稱>
優點 / 缺點 / 大致成本 / 操作負擔
### 選項 B：<名稱>
…
## 後果
<什麼變得容易，什麼變得困難，我們現在必須做什麼（遷移、訓練、
新的操作手冊），我們明確接受的風險。>
## 後續行動
- [ ] <具體任務，如果知道負責人請註明>
撰寫指導
- 撰寫背景時，讓新加入的成員在閱讀決策之前，就同意問題是真實存在的。
- 在相同的維度上比較選項：成本、操作負擔、鎖定效應、團隊熟悉度、交付時間、安全性/合規性。如果有數據，請提供數字（每月成本估算、RTO/RPO、吞吐量）。
- 誠實地說明落選選項的優勢。一個對替代方案進行斷章取義的 ADR 將不被信任。
- 後果包括負面的那些。「我們現在有兩個資料庫需要備份」屬於這一類。
- 保持不超過兩頁。連結到驗證測試（spikes）、基準測試和票證，而不是直接內嵌它們。
- 當以新記錄取代舊記錄時，更新舊 ADR 的狀態，並在兩者之間建立雙向連結。
當 $ARGUMENTS 被給定時
使用它作為標題；從中衍生出檔案名稱。