# Architecture Decision Records

## Status
`proposed`

## Context
We want to contextualize our architecture decisions and document them in a way that is easy to understand and easy to find.

Relates to #issue-number

## Decision
Use the [lightweight](https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/templates/decision-record-template-by-michael-nygard/index.md) Architecture Decision Records (ADR) format.

> An Architectural Decision (AD) is a justified software design choice that addresses a functional or non-functional requirement that is architecturally significant. An Architecturally Significant Requirement (ASR) is a requirement that has a measurable effect on a software system’s architecture and quality. An Architectural Decision Record (ADR) captures a single AD and its rationale; the collection of ADRs created and maintained in a project constitute its decision log. All these are within the topic of Architectural Knowledge Management (AKM), but ADR usage can be extended to design and other decisions (“any decision record”).

Extracted from <https://adr.github.io/>. 

This first ADR is both the record of our decision to use it and a template for future ADRs.

## Consequences
We now have a centralized place for architecture decisions that directly influence this repository, but maintaining requires cultural shift and discipline.

# MR: One-line summary of requested change

## Context
Brief comment on what is needed to know before reviewing the merge request and the why it was created.

[Resolves, Fixes] #issue-number

## Implementation
Brief description of the implementation approach, considered alternatives and any other important information not explicitly declared by the code itself. Focus on why it was done this way, not how or what (whitch is evidenced by the diff itself). 

## Impact
Sumarize important breaking changes or other non-clear impacts, such as: 
- Changes required by clients
- Side effects
- Anything that everybody needs to be aware