-
-
Notifications
You must be signed in to change notification settings - Fork 15
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[#376] [DC] Implementation Flow. Add arch. template
- Loading branch information
Showing
2 changed files
with
76 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,12 @@ | ||
# Fingrom Application Architecture | ||
|
||
[![License: CC BY-NC-ND 4.0](https://img.shields.io/badge/License-CC_BY--NC--ND_4.0-lightgrey.svg)](https://creativecommons.org/licenses/by-nc-nd/4.0/) | ||
|
||
## Architectural Decision Records | ||
|
||
An architectural decision record (ADR) serves as a comprehensive document that outlines the significant choices made by | ||
a team concerning the software architecture they intend to construct. Each ADR elucidates the specific architectural | ||
decision, its contextual factors, and the anticipated consequences. These records are not static but rather dynamic, | ||
mirroring a lifecycle that charts the evolution and impact of these decisions over time. They serve as a valuable | ||
reference, capturing the rationale behind critical architectural choices and their effects on the overall system, | ||
promoting transparency and understanding within the team. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,64 @@ | ||
<!-- Compilation of: MADR Template, ADR GitHub, and AWS ADR process --> | ||
|
||
# Description of proposal | ||
**Status:** Proposed | Accepted | Rejected | ||
**Date:** YYYY-MM-DD | ||
**Author:** Author Name | ||
|
||
## Context and Problem Statement | ||
|
||
{Describe the context and problem statement, using two to three sentences} | ||
|
||
## Decision Drivers | ||
|
||
* {decision driver 1, e.g., a force, facing concern, …} | ||
* … | ||
|
||
## Considered Options | ||
|
||
* {title of option 1} | ||
* … | ||
|
||
## Decision Outcome | ||
|
||
In the context of <use case/user story u>, facing <concern c> we decided for <option o> and neglected <other options>, | ||
to achieve <system qualities/desired consequences>, accepting <downside d/undesired consequences>, | ||
because <additional rationale>. | ||
|
||
|
||
### Consequences | ||
|
||
* Good, because {positive consequence, e.g., improvement of one or more desired qualities, …} | ||
* Bad, because {negative consequence, e.g., compromising one or more desired qualities, …} | ||
* … | ||
|
||
## Validation | ||
|
||
{describe how the implementation of/compliance with the ADR is validated. E.g., by a review or an ArchUnit test} | ||
|
||
|
||
## Pros and Cons of the Options | ||
|
||
### {title of option 1} | ||
|
||
{example | description | pointer to more information | …} | ||
|
||
* Good, because {argument a} | ||
* Good, because {argument b} | ||
* Neutral, because {argument c} | ||
* Bad, because {argument d} | ||
* … | ||
|
||
### {title of other option} | ||
|
||
{example | description | pointer to more information | …} | ||
|
||
* Good, because {argument a} | ||
* Good, because {argument b} | ||
* Neutral, because {argument c} | ||
* Bad, because {argument d} | ||
* … | ||
|
||
## Notes | ||
|
||
… |