# ADR-<số>: <Tiêu đề quyết định ngắn>

> **Mục đích:** ghi lại một quyết định kiến trúc khó đảo ngược — bối cảnh, lựa chọn, hệ quả — để vài tháng sau vẫn biết *vì sao*.
> **Ai điền:** người đề xuất quyết định (thường Kiến trúc giải pháp / Dev lead); review trong buổi review thiết kế.
> **Khi nào:** bất cứ khi nào một lựa chọn tốn kém để đổi lại (CSDL, kiểu kiến trúc, nhà cung cấp, giao thức, mô hình dữ liệu).
> **Khung:** theo đề xuất ADR của Michael Nygard (2011).

---

| Trường | Giá trị |
|---|---|
| Trạng thái | Đề xuất · Chấp nhận · Bị thay thế bởi ADR-… · Huỷ |
| Ngày | dd/mm/yyyy |
| Người quyết định | |
| Người được tham vấn | |
| Liên quan | Yêu cầu NFR-…, ADR-… |

## Bối cảnh
Vấn đề cần quyết định là gì? Các lực tác động (yêu cầu, ràng buộc, chi phí, đội, thời gian). Viết sự thật, không viết giải pháp.

## Các phương án đã xét
| Phương án | Ưu | Nhược | Chi phí / rủi ro |
|---|---|---|---|
| A | | | |
| B | | | |

## Quyết định
Chúng tôi chọn … vì …

## Bằng chứng / phép đo
Số đo, thử nghiệm, tài liệu đã dựa vào (ghi ngày đo và điều kiện đo).

## Hệ quả
- **Tích cực:**
- **Tiêu cực / đánh đổi chấp nhận:**
- **Việc phải làm theo:** (thẻ backlog)

## Khi nào xem lại
Điều kiện khiến quyết định này cần mở lại (vd: tải vượt …, giá nhà cung cấp đổi, yêu cầu mới).

---
*Mẫu tham khảo — https://cuongthai.com/about/quy-trinh.*
