An architecture decision record (ADR) preserves why an architectural choice was made, not merely what was chosen. It captures context, decision, status, and consequences so teams can revisit earlier reasoning instead of reconstructing it later. section 11.1.2 section 11.7
Build an ADR around the information that keeps a decision understandable and revisable:
- Title: name the architectural decision and optionally assign a reference number. section 11.1.2
- Status: distinguish options under discussion from decisions that are accepted, superseded, or rejected. section 11.1.2
- Context: record the circumstances, constraints, and information that shaped the choice. section 11.1.2
- Decision: state the selected architectural direction clearly. section 11.7
- Consequences: capture benefits, drawbacks, tradeoffs, and actionable fixes for disadvantages. section 11.7
Redesigning boundaries for “Anytime, Anywhere”
A team redesigning the BigScreen BBoM can use an ADR to connect the proposed architecture with its context and a Pros-Cons-and-Fixes list. The record gives absent stakeholders a structured way to review options asynchronously, while distilled domain-storytelling and C4 diagrams provide the surrounding flow and architecture. section 11.1.2 section 11.2.1
Figure 11.4 The ADR for redesigning the BBoM into clear boundaries to enable the “Anytime, Anywhere” campaign. It contains the new architecture for the system and the Pros-Cons-and-Fixes list.
Use the ADR canvas as a visual companion when a decision is being developed alongside collaborative modeling. section 11.1.2
