🌱 ADR - Architecture Decision Records

Registro de Decisões Arquiteturais (ADRs)

  • Why: registrar decisões arquiteturais significativas
  • What: registros da decisão em texto e contextualizados
  • When: quando qualquer proposta significativa surge (proposta, aceita, ou rejeitada)
  • How: criar uma pasta no repositório e um arquivo para cada decisão

Sempre que uma decisão arquitetural significativa (que impacta decisões futuras e como os desenvolvedores interagem ou escrevem código), a decisão deve ser documentada.

Geralmente são frutos de RFCs.

Exemplos de ADRs

/adr/0000-architecture-decision-records.md (meu modelo para sugerir o uso de ADRs, quando aplicável, em um novo repositório)

# 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 systems 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.

Inspiração para templates de merge requests

.github/pull_request_template.md

# 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

Links


🌱 Seedlings são ideias que recém tive e precisam de cultivo, não foram revisadas ou refinadas. O que é isso?


You'll only receive email when they publish something new.

More from Myreli
All posts