An architectural decision chooses the structure or organization of a software system to pursue a goal. Its quality must be judged separately from its eventual outcome: unforeseen events can make a sound decision produce a poor result, or the reverse. section 9.1.2
Monolith or microservices?
A team chooses a monolithic architecture after experiencing a poor microservices outcome. Two years later, the monolith becomes a big ball of mud. Calling the original decision bad may reflect resulting and hindsight bias rather than a fair evaluation of the information available at the time. section 9.1.2
Capture the reasoning, not only the selected architecture:
- Use an architectural decision record (ADR) to preserve why the decision was made and reduce future confusion. section 11.1.2
- Record the title, status, context, decision, and consequences. section 11.1.2
- Choose a flexible format and location—such as a canvas, Markdown, or Word document—that the team can access and update. section 11.1.2
Figure 11.4 The ADR for redesigning the BBoM into clear boundaries to enable the “Anytime, Anywhere” campaign. It contains the new architecture for the system and the Pros-Cons-and-Fixes list.
Inspect an ADR example linking a redesigned architecture, clear boundaries, the “Anytime, Anywhere” campaign, and a Pros-Cons-and-Fixes list. section 11.1.2
