GTI — ADR: Architecture Decision Record (B)

O ADR (Architecture Decision Record) documenta uma decisão arquitetural significativa e (potencialmente) irreversível. Deve conter contexto, alternativas consideradas, decisão tomada e suas consequências.

Exemplo YAML

---
id: GTI-ADR-0001
tipo: ADR
titulo: "Escolha do banco de dados — PostgreSQL"
status: aceita   # proposta | aceita | rejeitada | substituida | depreciada
autor: fulano.de.tal
data: 2026-04-11
substitui: null
substituido-por: null
impacto-em-pdp: false
---

contexto: >
  A solução precisa de um banco relacional com suporte a JSONB para dados semi-estruturados
  e com extensão PostGIS para dados geográficos.

alternativas-consideradas:
  - MySQL 8: descartado por limitações com JSONB e PostGIS
  - MongoDB: descartado por ausência de suporte a transações ACID complexas
  - PostgreSQL: escolhido

decisao: >
  Adotar PostgreSQL 16 como banco de dados principal.

consequencias:
  positivas:
    - Suporte nativo a JSONB e PostGIS
    - Extenso suporte da comunidade e ecossistema
  negativas:
    - Equipe precisa de capacitação em administração PostgreSQL

Ciclo de status do ADR

Status	Significado
`proposta`	Rascunho aberto para discussão
`aceita`	Decisão aprovada — entra em vigor
`rejeitada`	Proposta recusada — mantida para histórico
`substituida`	Superada por ADR mais recente (campo `substituido-por`)
`depreciada`	Ainda válida mas em fase de saída

Regras do ADR

Uma vez aceito, um ADR só pode ser alterado por um novo ADR que o substitua.
ADRs rejeitados são mantidos para registro histórico — nunca excluir.
ADRs com impacto em privacidade (impacto-em-pdp: true) devem ser comunicados ao PDP antes da implementação.
Toda decisão arquitetural significativa exige ADR — inclusive a decisão de não mudar algo.
O contexto deve descrever por que a decisão foi necessária, não apenas o que foi decidido.

← GTI Visão Geral · RFC →