Architecture Decision Records
Registos curtos do porquê de decisões que não cabem num comentário de código. Formato inspirado em Nygard ADR.
Cada ADR: contexto → decisão → consequências. Status: Aceite, Superseded, Deprecated.
| # | Título | Status |
|---|---|---|
| 0001 | Guard JWT global com opt-out @Public() | Aceite |
| 0002 | Duas conexões PostgreSQL (domínio vs auth) | Aceite |
| 0003 | Presença WebSocket em memória (não Redis) | Aceite |
| 0004 | Versionamento URI /api/v1 + rotas VERSION_NEUTRAL | Aceite |
| 0005 | Schema explícito, synchronize: false | Aceite |
Quando escrever um ADR
- Escolha que daqui a um ano alguém vai perguntar “porque não X?”
- Trade-off de consistência, latência, isolamento ou operação
- Introdução de dependência (SMTP, Redis, proxy externo)
Não é ADR: rename de DTO, novo campo opcional, correção de bug.