{short title, representative of solved problem and found solution}

Context and Problem Statement

{Describe the context and problem statement, e.g., in free form using two to three sentences or in the form of an illustrative story. You may want to articulate the problem in the form of a question. Make the scope of the decision explicit, for instance, by calling out or pointing at structural architecture elements (components, connectors, ...).}

Decision Drivers

• {decision driver 1, for instance, a desired software quality, faced concern, constraint or force}
• {decision driver 2}
• …

Considered Options

• {title of option 1}
• {title of option 2}
• {title of option 3}
• …

Decision Outcome

Chosen option: "{title of option 1}", because {justification, e.g., only option which meets a knock-out criterion decision driver | which resolves force {force} | comes out best (see below)}.

Consequences

• Good, because {positive consequence, e.g., improvement of one or more desired qualities, …}
• Bad, because {negative consequence, e.g., compromising one or more desired qualities, …}
• …

Confirmation

{Describe how the implementation / compliance of the ADR can/will be confirmed — e.g. a spike, a design review, or a test that exercises the decision. For a solo/small-team project like db4, this is usually "build a small end-to-end slice using the new shape before committing more domains to it."}

Pros and Cons of the Options

{title of option 1}

• Good, because {argument a}
• Neutral, because {argument b}
• Bad, because {argument c}

{title of other option}

• Good, because {argument a}
• Neutral, because {argument b}
• Bad, because {argument c}

More Information

{Additional evidence for the decision outcome, links to related ADRs, external references consulted, and notes on when/how this decision should be revisited.}