|
|
|
@ -1,5 +1,22 @@ |
|
|
|
# Architecture Decision Records |
|
|
|
# Architecture Decision Records (ADR) |
|
|
|
|
|
|
|
This is a location to record all high-level architecture decisions in the tendermint project. Not the implementation details, but the reasoning that happened. This should be refered to for guidance of the "right way" to extend the application. And if we notice that the original decisions were lacking, we should have another open discussion, record the new decisions here, and then modify the code to match. |
|
|
|
This is a location to record all high-level architecture decisions in the tendermint project. |
|
|
|
|
|
|
|
Read up on the concept in this [blog post](https://product.reverb.com/documenting-architecture-decisions-the-reverb-way-a3563bb24bd0#.78xhdix6t). |
|
|
|
You can read more about the ADR concept in this [blog post](https://product.reverb.com/documenting-architecture-decisions-the-reverb-way-a3563bb24bd0#.78xhdix6t). |
|
|
|
|
|
|
|
An ADR should provide: |
|
|
|
|
|
|
|
- Context on the relevant goals and the current state |
|
|
|
- Proposed changes to achieve the goals |
|
|
|
- Summary of pros and cons |
|
|
|
- References |
|
|
|
- Changelog |
|
|
|
|
|
|
|
Note the distinction between an ADR and a spec. The ADR provides the context, intuition, reasoning, and |
|
|
|
justification for a change in architecture, or for the architecture of something |
|
|
|
new. The spec is much more compressed and streamlined summary of everything as |
|
|
|
it stands today. |
|
|
|
|
|
|
|
If recorded decisions turned out to be lacking, convene a discussion, record the new decisions here, and then modify the code to match. |
|
|
|
|
|
|
|
Note the context/background should be written in the present tense. |
Ethan Buchman