ADR, or Architecture Decision Records, is a collection of documents where you capture the most important technical decisions of the company.
Typical ADR Structure:
- Date: Useful for visibility and tracking purposes.
- Status: Indicate whether the decision is proposed, accepted, rejected, deprecated, or superseded. If the decision is still under discussion, mark it accordingly so engineers do not pick it up for implementation until it is finalised.
- Context: Briefly describe why this architectural decision is needed. It could include historical information on how similar issues were solved previously and the pain points they brought to the product.
- Decision: Note what has been decided.
- Consequences: Detail any required actions from teams. Should they consider implementing refactoring, or does the ADR apply only to new code?
- Optional: Include examples of code if applicable.
Discover more templates here
ADRs should be created only for the most significant technical discussions, such as the selected development language, database, and architecture patterns that should be applied to all services. It’s important to keep the list of ADRs short and organised. An excessive number of architectural solutions can reduce the quality of their application.
Learn more about ADR
Top comments (0)