Skip to content

Commit

Permalink
[#376] [DC] Implementation Flow. Add arch. template
Browse files Browse the repository at this point in the history
  • Loading branch information
lyskouski committed Nov 12, 2023
1 parent 0e7579c commit 94ad86d
Show file tree
Hide file tree
Showing 2 changed files with 76 additions and 0 deletions.
12 changes: 12 additions & 0 deletions docs/architectural-flow/README.md
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.
64 changes: 64 additions & 0 deletions docs/architectural-flow/decisions/000000_template.md
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

0 comments on commit 94ad86d

Please sign in to comment.