AJR/TechRadarAJR
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update adr.md

Browse Source
This commit is contained in:
Roland Edwards, AOE GmbH
2018-05-16 15:31:59 +02:00
committed by GitHub
parent 830ec509c9
commit 9c7c4029be
1 changed files with 10 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
radar/2017-10-01/adr.md
View File

@@ -6,21 +6,21 @@ quadrant: methods-and-patterns
--- ---
Architecture Decision Records Architecture Decision Records
Is a lightweight documentation of important architecture decisions taken by the team. ADR is a lightweight documentation of important architecture decisions taken by the team.
Without documentation of the architecture and the architecture decisions, new team members can only do two things: Without documentation of the architecture and the architecture decisions, new team members can only do two things:
* either (blindy) accept what they find and see or * either (blindy) accept what they find and see or
* (blindy) change things * (blindy) change things
Both is of course not right. It goes without saying that both options aren't right.
Therefore we suggest to document the important architecture decisions. We are using a simple tool like https://github.com/npryce/adr-tools and store them in version control. Therefore, we suggest documenting the important architecture decisions. We use a simple tool such as https://github.com/npryce/adr-tools and store them in version control.
In bigger projects with many teams we also establish a regular "architecture board / coi" with regular meetings. In larger projects with many teams we also establish a regular "architecture board / COI" with regular meetings.
Often the architecture decision are taken in such meetings. Often, the architecture decisions are taken in such meetings.
The main purpose of this documentation is: The main purpose of this documentation is to:
* inform new team members about the previous architecture decisions and its purpose and backgrounds * inform new team members about the previous architecture decisions and their purpose and backgrounds
* inform the whole team (also all the people who where absent) * inform the whole team (including all people who were absent)
* documentation that can be used to remeber things (e.g. conventions, patterns, etc) * create documentation that can be used to remember things (e.g. conventions, patterns, etc.)