Chapter 12. Effective Practices
Many methods, techniques, and practices for architecting and designing software exist, but it is not enough to just follow them, create the outputs, and move on. The artifacts you create must be constructed and used effectively to be of any use in the overall architecture. The patterns in this chapter will enable you to put the techniques discussed into effective practice.
ADRs
An architecture decision record (ADR) is a record of an architectural decision and the reasoning behind it that can be used in the decision-making process itself. ADRs are key to communicating architectural decisions made and the outcome of the decision, not only to architects but to all stakeholders. Many decisions are made throughout the life of a product or project, but without documenting these decisions, they (and the reasoning that supports them) are easily lost and forgotten.
Note
ADRs were originally envisioned by Michael Nygard in 2011, and his introductory blog post is structured as an ADR. His original ADR template is now often extended to record the decision-making process as well as the decision made.
Here are some situations that ADRs help you avoid:
-
A decision is made early in the life of a product. Later, an individual or team decides to change that decision. Without knowing how and why the initial decision was made, the change may cause huge problems. Maybe a particular technology was chosen to meet one or more requirements, and overriding that choice ...