Below is the (markdown) template I use for my Architectural Decision Records (ADRs). It is a shortened version of [this template](https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/templates/decision-record-template-madr/index.md) with slight renaming to make things clearer. It is explicitly designed to be as minimal as possible while providing the main benefit that I personally care about from ADRs, which is **enabling better conversations about decisions and, thus, better decision-making. # Template ``` # [short title of problem] * Status: [proposed | rejected | accepted | deprecated | … | superseded by [ADR-0005](0005-example.md)] <!-- optional --> * Deciders: [list everyone involved in the decision] <!-- optional --> * Links: [list all the related links] <!-- optional --> ## Context and Problem Statement [Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.] ## Evaluation Criteria * [criteria 1, e.g., a force, facing concern, …] * [criteria 2, e.g., a force, facing concern, …] * … <!-- numbers of criteria can vary --> ## Considered Options ### [option 1] [example | description | pointer to more information | …] <!-- optional --> * Pros & Cons: * Good, because [argument a] * Good, because [argument b] * Bad, because [argument c] * … <!-- numbers of pros and cons can vary --> Does/doesn't meet criteria and why: yes/no ### [option 2] [example | description | pointer to more information | …] <!-- optional --> * Pros & Cons: * Good, because [argument a] * Good, because [argument b] * Bad, because [argument c] * … <!-- numbers of pros and cons can vary --> Does/doesn't meet criteria and why: yes/no ### [option n] [example | description | pointer to more information | …] <!-- optional --> * Pros & Cons: * Good, because [argument a] * Good, because [argument b] * Bad, because [argument c] * … <!-- numbers of pros and cons can vary --> Does/doesn't meet criteria and why: yes/no ## Decision Recommendation Recommend option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion evaluation criteria | which resolves force force | … | comes out best (see below)]. ### Expected Positive Consequences <!-- optional --> * [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …] * … ### Expected Negative Consequences <!-- optional --> <!-- Every decision has tradeoffs and negative consequences. Which ones can we already foresee if we chose the perceived best option? --> * [e.g., compromising quality attribute, follow-up decisions required, …] * … ```