🐾Why ADRs should be used not only by architects🐾
❓Architecture decision record (ADR) is a document that describes architecture decisions related to system design. It can describe decisions related to choice of specific tool or technology.
Reasons why it is useful for developers:
🔹 You have a track record of all decisions made, it makes onboarding of new architects and developers easier and quicker.
🔹You have context of all decisions made.
🔹You don’t waste time to double check options which have already been rejected in ADRs.
🔹It easier to write fitness functions based on set of ADRs.
Sections of ADR:
🔸Title and status: you can use any subset of states which suits company’s purpose, e.g. accepted, rejected, deprecated, etc.
🔸Context: explain problem that you are solving, constraints that you have and assumptions that you made. Include all relevant information that can help understand situation better, e.g. other ADRs that impact this one.
🔸Decision: describe considered alternatives and final decision. Include arguments and quality attributes you considered while making decision.
🔸Consequences: describe how this decision will impact the system, whether this decision triggers the need of more ADRs and any actions required from the team.
Repository with ADR templates: https://github.com/joelparkerhenderson/architecture-decision-record
If you like this post, you can share APAWS newsletter with friends: