Architecture Decision Record

Adopt the reader point of view, surfacing compelling information at the top:

• I can check metadata section and decide to leave if ADR status is not the one I am interested in
• If status is accepted, I can take note of the decision
• To better understand decision, I can look at context section
• I can refine my understanding by parsing options decision was made of
• Eventually, I can read over consequences to better grasp pros and cons for every options
• Ultimately, I can dive in underlying discussion process

Architecture decisions are important and you should probably track them. There is no per say bad choices, provided that you can explain why you made it. A choice can appear to be unlucky or inappropriate if we analyze it through our current perspective, but can make sense if we do it via past prism. Thus, the importance of tracking those choices to be able to rewind and replay without be tempting to rewrite the history. Of course, this applies to many domains, especially History. Let’s see how it fits into software crafting.