Utilização de Architectural Decision Records em Markdown (MADR)

Contexto e Declaração do Problema

A Amplimed precisa registrar decisões relevantes tomadas ao longo do desenvolvimento de seus projetos, independentemente de essas decisões estarem relacionadas à arquitetura, ao código ou a outros aspectos técnicos e organizacionais.
Para garantir consistência, rastreabilidade e facilidade de consulta no futuro, é necessário definir qual formato e estrutura devem ser adotados para esses registros de decisão.

Opções Consideradas

• MADR 4.0.0 – Markdown Architectural Decision Records
• Template de Michael Nygard – Primeira formalização do conceito de ADR
• Sustainable Architectural Decisions – Y-Statements
• Outros templates listados em https://github.com/joelparkerhenderson/architecture_decision_record
• Formato livre – Sem convenção definida de estrutura ou padrão

Decisão

Opção escolhida: “MADR 4.0.0”, porque:

• Suposições implícitas passam a ser explicitadas. A documentação de decisões é essencial para permitir que outras pessoas compreendam, no futuro, por que determinadas escolhas foram feitas.
  Esse princípio está alinhado com o conceito apresentado em “A rational design process: How and why to fake it”.
• O MADR permite o registro estruturado de qualquer tipo de decisão relevante, não apenas decisões estritamente arquiteturais.
• O formato MADR é enxuto e compatível com o estilo de desenvolvimento da Amplimed.
• A estrutura é clara, fácil de entender e favorece o uso contínuo e a manutenção ao longo do tempo.
• O projeto MADR é ativo e amplamente adotado, reduzindo o risco de obsolescência do padrão.

Este ADR define o MADR como padrão oficial para o registro de decisões técnicas e arquiteturais na Amplimed.