Blame
|
1 | # Architecture Decisions |
||||||
| 2 | ||||||||
| 3 | Use an Architecture Decision Record (ADR) for a choice that will constrain future work or otherwise be expensive to rediscover. |
|||||||
| 4 | ||||||||
| 5 | Good ADR subjects include persistence models, compatibility strategy, identity schemes, protocol boundaries, framework selection and cross-product service contracts. Routine implementation details do not need an ADR. |
|||||||
| 6 | ||||||||
| 7 | ## Decision states |
|||||||
| 8 | ||||||||
| 9 | - **Proposed** — under review. |
|||||||
| 10 | - **Accepted** — current decision. |
|||||||
| 11 | - **Superseded** — replaced by a newer ADR; retain the old record and link both directions. |
|||||||
| 12 | - **Rejected** — considered but not chosen; retain when the rejected option is likely to recur. |
|||||||
| 13 | ||||||||
| 14 | An ADR should explain context, decision, alternatives, consequences and follow-up work. Use [[Templates/Architecture-Decision-Record]]. |
|||||||