Architecture Decision Records nasceram para o software — mas viraram Any Decision Records. Um guia completo sobre como capturar decisões importantes em documentos curtos, versionados e à prova de esquecimento.
Toda base de código, todo processo de marketing e toda operação carrega uma camada invisível: o conjunto de decisões que levou tudo a ser do jeito que é. O código você consegue ler. A decisão por trás dele, quase nunca. Seis meses depois, ninguém lembra por que a fila de mensagens entrou no lugar da chamada síncrona, por que o modelo de atribuição mudou, ou por que aquele fornecedor foi descartado. Quem chega depois tem só duas opções ruins: aceitar a decisão sem entender, ou reverter sem entender. O ADR existe para criar uma terceira opção.
O que é um ADR
Um ADR (Architecture Decision Record) é um documento curto que captura uma única decisão relevante para um produto ou sistema, junto com o contexto em que ela foi tomada e as consequências que ela traz. A definição mais difundida é a de Martin Fowler: um documento que deve ter poucas páginas e conter a decisão, o contexto e as ramificações significativas — sem virar uma descrição completa do sistema.
A coleção de todos os ADRs de um projeto forma o seu log de decisões (decision log), uma espécie de diário de bordo que permite reconstruir a história de um sistema lendo os registros em ordem. A peça de engenharia é deliberadamente leve: texto curto, em Markdown ou AsciiDoc, versionado junto com o código.
O ponto mais sutil — e mais valioso — é que escrever um ADR serve a dois propósitos ao mesmo tempo. Funciona como registro, para que daqui a meses ou anos alguém entenda por que o sistema é assim. E funciona como ferramenta de pensamento: o ato de escrever obriga o time a tornar explícitos os trade-offs, e costuma fazer divergências virem à tona para serem discutidas antes de o código ser escrito.
O vocabulário: AD, ADR, ADL, ASR
A comunidade em torno do tema padronizou quatro siglas que vale conhecer, porque elas aparecem em quase toda a literatura.
- AD — Architectural Decision. A escolha de design em si, justificada, que atende a um requisito relevante (funcional ou não funcional).
- ADR — Architecture Decision Record. O documento que captura uma AD e seu raciocínio.
- ADL — Architecture Decision Log. A coleção de todos os ADRs de um projeto ou organização.
- ASR — Architecturally-Significant Requirement. Um requisito com efeito mensurável sobre a arquitetura e a qualidade do sistema.
Tudo isso vive sob o guarda-chuva da Gestão de Conhecimento Arquitetural (AKM, Architectural Knowledge Management). A boa notícia: você não precisa decorar nada disso para começar. Precisa apenas de um arquivo de texto e da disciplina de escrevê-lo no momento da decisão.
A história: de Nygard a “Any Decision Record”
O termo foi cunhado por Michael Nygard em novembro de 2011, num post chamado Documenting Architecture Decisions, escrito enquanto trabalhava na consultoria Relevance (depois Cognitect). Nygard não inventou a ideia de um log de decisões — ele se inspirou nos decision logs de Philippe Kruchten e no estilo de escrita dos software patterns — mas defendeu algo novo: um documento leve, com foco na decisão em si, compatível com métodos ágeis.
A partir daí, o formato evoluiu em camadas:
Em 2012, Olaf Zimmermann apresentou os Y-Statements (ou (WH)Y-statements) — uma decisão inteira em uma única frase estruturada, criada porque patrocinadores de projeto pediam “uma decisão por slide”.
Em 2017 nasceu o MADR (Markdown Architectural Decision Records), de Oliver Kopp e Olaf Zimmermann, transformando o formato em seções de Markdown — mais fácil de ler e de versionar do que a frase longa do Y-Statement.
E aqui está a virada conceitual mais interessante. Em 2022, na versão 3.0, o projeto MADR foi renomeado de “Markdown Architectural Decision Records” para “Markdown Any Decision Records”, acompanhando o movimento informal apelidado de “ADR = Any Decision Record?”. A premissa: existe debate eterno sobre o que é “arquiteturalmente significativo” — então, em vez de brigar com essa fronteira, melhor admitir que qualquer decisão importante merece ser registrada de forma estruturada.
Nuance que quase todo artigo erra
Em 2024, a versão 4.0 do MADR voltou o nome para “Markdown Architectural Decision Records”. A sigla continua MADR e o template segue servindo para registrar qualquer decisão — só o rótulo oscilou. Ou seja: “Any Decision Record” é menos um produto e mais uma filosofia de uso.
Por que usar — e a ressalva honesta
Os ganhos relatados de forma mais consistente são quatro:
- Preservar o porquê, não só o quê. O título de um pull request diz o que mudou. O ADR diz por que aquilo era a resposta certa naquele momento, quais restrições valiam e o que foi descartado.
- Acelerar onboarding. Conhecimento que normalmente é “institucional” e mora na cabeça de poucos vira algo que se lê em ordem cronológica.
- Evitar aceitação e reversão cegas. O objetivo original de Nygard: quem chega depois não precisa nem engolir nem desfazer uma decisão sem entender o raciocínio.
- Resiliência e rastreabilidade. O log mostra a evolução do sistema e dos trade-offs ao longo do tempo, conforme o negócio muda.
A prática tem peso de mercado. O ThoughtWorks Technology Radar colocou os “Lightweight Architecture Decision Records” no anel Adopt — sua recomendação mais forte. A AWS recomenda ADRs em seu Prescriptive Guidance, e o Azure Well-Architected Framework também os destaca.
“Documentação demais pode ser substituída por código e testes legíveis. Mas, num mundo de arquitetura evolutiva, certas decisões de design precisam ser registradas — para o time futuro e para a supervisão externa.”— paráfrase do veredito “Adopt” do ThoughtWorks Technology Radar
Anatomia de um ADR
O template original de Nygard é minimalista e continua sendo o mais usado. Ele tem essencialmente cinco partes.
Uma regra de ouro de escrita: siga a pirâmide invertida do jornalismo — a informação mais importante primeiro. Quem abre o documento deve entender a decisão nas primeiras linhas, e só descer aos detalhes se precisar. Para a seção de contexto, vale citar a descrição de Nygard: as “forças em jogo, incluindo aspectos tecnológicos, políticos, sociais e locais do projeto”.
Status e imutabilidade
Aqui está o detalhe que separa um log confiável de uma pasta de rascunhos: um ADR aceito é imutável. Só o seu status muda. Se a realidade muda, você não reescreve o registro antigo — você cria um novo ADR que substitui o anterior, e marca o antigo como “substituído”, com um link para o sucessor.
Por quê? Porque assim o histórico nunca fica “desatualizado”. Mesmo uma decisão que hoje não vale mais foi verdadeira um dia — e essa verdade datada é justamente a informação que você quer preservar.
Os três templates essenciais
Existem dezenas de formatos — o repositório de Joel Parker Henderson reúne mais de vinte. Mas, na prática, três cobrem 95% dos casos.
| Template | Forma | Brilha quando… |
|---|---|---|
| Nygard | Seções curtas: Título, Status, Contexto, Decisão, Consequências. | Você quer o mínimo viável e um log fácil de diferenciar no Git. |
| MADR | Markdown com YAML; acrescenta “Opções consideradas” com prós e contras, decisores e confirmação. Vem em versões full e minimal. | A decisão tem alternativas reais que precisam ser comparadas lado a lado. |
| Y-Statement | Uma frase estruturada: contexto → preocupação → escolha → para alcançar → aceitando → porque. | Você precisa de algo que caiba “em um slide” para liderança. |
O molde do Y-Statement
Vale guardar a estrutura, porque ela é um ótimo exercício mental mesmo quando você usa outro formato:
# Y-Statement (Zimmermann) No contexto de <caso de uso / história>, enfrentando <preocupação / requisito não funcional>, decidimos por <opção escolhida> e descartamos <alternativas>, para alcançar <qualidade / benefício>, aceitando <desvantagem / custo>, porque <justificativa>.
Como nota de rodapé histórica: existe hoje até uma variante em YAML (chamada YADR), pensada para ser processada por ferramentas, e o padrão internacional ISO/IEC/IEEE 42010 sugere nove itens de informação para registrar decisões.
Dois exemplos completos
Teoria o suficiente. Veja a mesma ideia aplicada a dois mundos: uma decisão de software (formato Nygard) e uma decisão de operação/RevOps (formato MADR) — para deixar claro como o ADR sai da arquitetura e vira Any Decision Record.
Processar webhooks de entrada por fila de mensagens
- Contexto
- Integrações de terceiros disparam picos de webhooks. O processamento síncrono atual derruba o tempo de resposta e perde eventos quando o provedor não recebe um 200 rápido.
- Decisão
- Vamos receber o webhook, persistir o payload bruto e devolver 200 imediatamente, processando de forma assíncrona via fila (SQS). O endpoint só valida assinatura e enfileira.
- Consequências
-
- Positivo: resiliência a picos, reprocessamento por replay, latência de resposta estável.
- Negativo: processamento deixa de ser imediato; precisamos projetar idempotência e uma fila de mensagens mortas (DLQ).
Adotar atribuição data-driven no lugar de last-click
- Contexto e problema
- O modelo last-click credita 100% da conversão ao último toque e mascara o papel de topo e meio de funil. Isso distorce o CAC por canal e leva a cortar verba de canais que assistem a conversão.
- Opções consideradas
-
- Last-click — simples, mas enviesado para fundo de funil.
- Linear / time-decay — distribui crédito, mas com pesos arbitrários.
- Data-driven — usa o histórico de jornadas para estimar contribuição real de cada toque.
- Resultado da decisão
- Escolhemos atribuição data-driven, porque temos volume de conversões suficiente para o modelo ser estável e o ganho em alocação de verba supera a perda de simplicidade. Aceitamos menor transparência do cálculo e a necessidade de reeducar o time sobre como ler os relatórios.
- Decisores
- Head de Growth, Head de Dados. Revisar em 90 dias
Além da arquitetura: Any Decision Record
Uma vez que o time se acostuma a escrever decisões, o formato vaza naturalmente para fora da engenharia. O próprio MADR afirma a premissa: como há debate sem fim sobre o que é “arquiteturalmente significativo”, melhor capturar qualquer decisão importante de forma estruturada.
Não é teoria solta — há precedentes nomeados. O ThoughtWorks documentou os Design System Decision Records: pegando emprestada a ideia dos ADRs para registrar decisões de design system com pesquisa e resultados de experimento, o que reduziu o tempo de onboarding e alinhou times. É exatamente esse caminho que as próximas três seções percorrem — saindo da engenharia e adaptando o registro para decisões de marketing, comercial e de processo.
O Registro de decisão de negócio
Times de marketing, vendas e operações sofrem da mesma amnésia que a engenharia — só que pior, porque quase nada fica versionado. Por que o desconto-padrão virou 15%? Por que paramos de investir naquele canal que parecia ir bem? Qual era a definição de MQL antes de alguém mudá-la no meio de uma reunião? Esse conhecimento costuma morar na cabeça de duas ou três pessoas e vai embora junto com elas. O Registro de Decisão de Negócio — vamos chamar de BDR, Business Decision Record — é o mesmo ADR, com o vocabulário ajustado para fora do código.
O que muda em relação ao formato técnico é pouco, mas importa. Decisão de negócio costuma ter mais gente envolvida e uma métrica para acompanhar. Então o template ganha dois campos — quem decidiu e foi consultado, e qual indicador vai dizer se a decisão acertou — e mantém todo o resto, inclusive a regra de ouro: registro aceito é imutável; se mudar, cria-se um novo que substitui o anterior.
<Verbo no presente + a decisão em uma linha>
- Contexto e problema
- O que está acontecendo e por que precisamos decidir agora. Os fatos, não as opiniões.
- Opções consideradas
- As alternativas reais que estavam na mesa — incluindo “não fazer nada”, quando couber.
- Critérios de decisão
- O que pesou na escolha: CAC, payback, esforço de implementação, risco, impacto no time.
- Decisão
- A escolha, em voz ativa, e o que estamos aceitando de desvantagem ao fazê-la.
- Quem decidiu · consultados
- Responsável pela decisão e quem foi ouvido. Evita o “quem aprovou isso?” seis meses depois.
- Impacto esperado e métrica
- O indicador que vamos observar e a meta. Sem isso, ninguém sabe se a decisão funcionou.
- Data de revisão
- Quando voltar a olhar — normalmente amarrada ao ciclo do negócio (30, 60, 90 dias).
Onde guardar quando o time não é técnico. Desenvolvedores deixam ADRs no Git, junto do código. Para marketing e comercial, isso costuma gerar mais atrito do que valor. Use uma base no Notion ou no Confluence, ou uma pasta no Google Drive com um documento por decisão e um índice numerado. O formato é secundário; o que não pode faltar é: uma decisão por registro, numeração sequencial, imutabilidade e um link a partir do lugar onde a decisão se manifesta — o dashboard, o playbook, a descrição do campo no CRM.
Mapa de decisões por área
Nem toda escolha vira registro — só as que “sustentam carga”, aquelas que alguém vai questionar lá na frente. Estes são os candidatos mais comuns fora da engenharia, com a métrica que normalmente está em jogo:
| Área | Decisões que merecem um registro | Métrica em jogo |
|---|---|---|
| Marketing | Modelo de atribuição; realocação de verba entre canais; convenção de nomenclatura de campanha; pivô de posicionamento/mensagem; escolha da plataforma de automação. | CAC, ROI por canal, taxa de conversão. |
| Comercial / Vendas | Política de desconto; pricing e empacotamento; definição de ICP; segmentação e territórios; mudança no plano de comissionamento. | Ticket médio, win rate, ciclo de vendas, payback de CAC. |
| RevOps / Processos | SLA e handoff entre marketing e vendas; regras de roteamento de leads; definição dos estágios do funil no CRM; fluxo de aprovação; governança de dados. | Taxa de aceite de MQL, tempo de 1º contato, vazamento de funil. |
| Produto / Pricing | Escopo de release; modelo de cobrança; o que entra no plano X vs. Y; descontinuar um recurso. | NRR, churn, taxa de expansão. |
| Dados / Ferramentas | Seleção de fornecedor (CRM, CDP, BI); fonte da verdade de uma métrica; consolidação de stack. | Custo por seat, adoção, qualidade do dado. |
Três decisões de negócio na prática
Os mesmos campos, aplicados a três decisões que todo time de go-to-market acaba tomando — e quase nunca registra.
Redefinir MQL e o SLA de follow-up entre marketing e vendas
- Contexto e problema
- Vendas diz que o MQL não converte; marketing diz que o lead esfria sem contato. Não existe definição compartilhada nem prazo combinado — cada lado opera com a sua régua.
- Decisão
- MQL passa a ser lead com score ≥ 60 e fit de ICP confirmado. Vendas assume o primeiro contato em até 24h úteis; lead não trabalhado em 48h volta automaticamente para nutrição.
- Quem decidiu · consultados
- Head de Marketing e Head de Vendas (decisão conjunta); RevOps consultado para a regra de roteamento.
- Impacto esperado e métrica
- Acompanhar taxa de aceite de MQL e tempo de 1º contato. Meta: aceite ≥ 70%. Revisar em 60 dias
Migrar de preço único para três planos (Good / Better / Best)
- Contexto e problema
- O preço único afasta os dois extremos: parece caro para o small e barato (pouco robusto) para o enterprise. Falta uma âncora de valor que oriente a escolha.
- Opções consideradas
-
- Manter preço único — simples, mas sem âncora.
- Dois planos — melhora pouco a percepção de valor.
- Três planos com o do meio como recomendado — usa o efeito de ancoragem.
- Decisão
- Três planos, com o intermediário destacado como recomendado. Aceitamos maior complexidade de comunicação e a necessidade de reposicionar toda a página de preços.
- Impacto esperado e métrica
- Ticket médio e taxa de upgrade entre planos. Revisar em 90 dias
Consolidar e-mail e automação numa única plataforma
- Contexto e problema
- Duas ferramentas sobrepostas inflam o custo do stack e quebram a atribuição, porque o lead transita entre elas sem rastro único.
- Decisão
- Migrar tudo para a plataforma A em 60 dias e desligar a B após validação. Aceitamos o custo da migração e o risco do período de transição.
- Impacto esperado e métrica
- Custo do stack por mês e integridade da atribuição ponta a ponta.
- Nota
- Substituído pelo BDR-0019, que reverteu parte da consolidação após mudança de pricing do fornecedor — exemplo de por que registros antigos não se apagam: eles explicam o caminho.
Por que isso é maturidade de RevOps
Um funil previsível depende de decisões consistentes — e decisões só ficam consistentes quando alguém consegue dizer, com confiança, por que a regra atual existe. O log de decisões transforma “conhecimento institucional” frágil em um ativo que sobrevive à rotatividade do time, ao onboarding e à próxima troca de ferramenta.
Ferramentas
Você não precisa de software algum para começar — um editor de texto e a pasta certa bastam. Mas, conforme o log cresce, algumas ferramentas ajudam:
- adr-tools — scripts em bash, de Nat Pryce, para criar e gerenciar ADRs no formato Nygard. O ponto de partida clássico.
- Log4brains — base de conhecimento docs-as-code: você escreve ADRs no editor e a ferramenta publica um site estático com linha do tempo e busca. Roda com
npm install -g log4brainselog4brains init. - ADR Manager — plugin de VS Code e app web (conecta a um repositório GitHub) para criar e editar MADRs com formulário.
- dotnet-adr · pyadr — CLIs para os ecossistemas.NET e Python.
- adr.zone — gerador web com suporte a múltiplos formatos (Nygard, MADR, Y-Statement).
- Intelligence — software da Incuca IA-first para equipes de RevOps, pronto para documentar as decisões e acompanhar as métricas e resultados em tempo real
Boas práticas e anti-padrões
Faça
- Escreva no momento da decisão, não semanas depois — o contexto evapora rápido.
- Registre as decisões “que sustentam carga”, não as triviais nem as cósmicas. “Escolhemos Tailwind em vez de Bootstrap” raramente importa; “guardamos o estado de sessão no banco em vez de em memória” importa muito.
- Use pull request para revisar. O ADR proposto entra como PR; a discussão acontece ali; o merge na branch principal significa “aceito”.
- Linke do código para o ADR. Um comentário curto em cada “costura” arquitetural, apontando para o registro, faz o documento aparecer no exato momento em que é útil.
Evite
- Transformar o ADR em changelog. Ele não substitui boas mensagens de commit nem registra cada mudancinha.
- Reescrever registros aceitos. Decisão mudou? Novo ADR, e marque o antigo como substituído.
- “Teatro de documentação”. Sem cadência de revisão e sem confiança do time, o log vira write-only e morre. A diferença entre quem mantém ADRs por anos e quem abandona não é o template — é a operação.
IA: escrever, buscar e não afogar
Os dois maiores motivos para um time não manter registros de decisão sempre foram: escrever dá trabalho, e achar o registro certo depois dá ainda mais. A IA generativa ataca exatamente esses dois pontos — e é por isso que ela muda a economia da prática. Mas convém separar o que ela resolve do que ela não resolve, porque é aí que mora a armadilha.
Eixo 1 — Escrever: do “kernel de verdade” ao rascunho
O padrão que tem funcionado não é pedir “escreva um registro do zero”, e sim começar por uma frase só — o kernel de verdade: "decidimos X porque Y" — e deixar a IA expandir para o registro completo no seu template. Agentes conseguem ler o código, um diff de pull request, uma transcrição de reunião ou uma thread de Slack e devolver um primeiro rascunho com contexto, opções e consequências já preenchidos. No mundo do negócio, isso significa transformar a call de RevOps de sexta-feira num rascunho de BDR antes de o contexto evaporar.
Eixo 2 — Buscar: é aqui que “documentação demais” deixa de doer
Este é o ponto que você levantou, e é o mais subestimado. O medo de manter um log grande sempre foi: “ninguém vai ler 200 registros”. Com recuperação aumentada (RAG) sobre o log, você não lê — você pergunta. “Por que mudamos o modelo de atribuição?” devolve os dois ou três registros que importam, com o raciocínio, em vez de uma pasta intimidadora. O volume deixa de ser passivo e vira um ativo consultável. Documentação demais só vira problema quando a única forma de acessá-la é lendo tudo.
A via de mão dupla: o log também alimenta a IA
Há uma simetria elegante aqui. Um log de decisões bem mantido é exatamente o tipo de fonte confiável e datada que faz assistentes e agentes de código acertarem mais — é contexto de qualidade, não ruído. Em 2026 isso virou debate aberto: o registro de decisão (o “porquê” histórico, passivo) convive com arquivos de instrução para agentes, tipo AGENTS.md (o “o que precisa ser verdade”, ativo). Não competem: o registro explica a escolha; o arquivo de instrução faz a IA respeitá-la na prática.
A armadilha
O gargalo de um bom registro nunca foi a digitação — foi o pensamento. Escrever obrigava o time a encarar os trade-offs e trazer a discordância à tona. Se a IA escreve e ninguém revisa, você troca “documentação de menos” por “documentação plausível e vazia” — e, em escala, isso é o teatro de documentação da seção anterior, só que automatizado e mais rápido. A regra: a IA rascunha e recupera; o humano decide, confirma e assina. Vale até registrar quem decidiu — pessoa ou agente.
Repare que a disciplina muda de lugar, não desaparece. Antes, o trabalho era escrever. Agora que gerar ficou barato, o trabalho é curar: decidir o que merece um registro, confirmar o raciocínio e marcar o que foi superado. A IA não dispensa o critério — ela o concentra na parte que sempre importou.
Como começar em 5 passos
- Escreva o ADR-0001 sobre adotar ADRs. Sério: o primeiro registro do log costuma ser a decisão de usar ADRs. Isso já testa o formato e documenta a própria escolha.
- Escolha um template. Comece com Nygard (mínimo) ou MADR minimal (se você compara opções com frequência). Pode trocar depois.
- Defina o lugar. Crie
docs/decisions/no repositório principal e combine a numeração sequencial. - Combine o ritual. ADR proposto entra por PR; revisão pelos afetados; merge = aceito. Reserve 15 minutos numa cerimônia recorrente para olhar os “propostos”.
- Faça a primeira decisão real valer a pena. Pegue uma escolha que o time vai questionar daqui a seis meses e registre-a hoje. Um log com cinco bons registros já vale mais que zero.
Regra de bolso
Se daqui a seis meses alguém vai perguntar “por que diabos isso é assim?”, a resposta deveria estar a uma busca de distância no repositório. Esse é o teste para saber se uma decisão merece um ADR.
Perguntas frequentes
As duas coisas. O termo nasceu como Architecture Decision Record (Nygard, 2011). O movimento “Any Decision Record” é uma ampliação de uso: o mesmo formato serve para qualquer decisão importante, não só de arquitetura. O projeto MADR chegou a adotar oficialmente “Any” na versão 3.0 (2022) e voltar para “Architectural” na 4.0 (2024) — o que mudou foi o rótulo, não a ideia.
Um RFC (Request for Comments) é um documento de proposta, geralmente mais longo, usado para coletar feedback antes de decidir. O ADR é o registro enxuto da decisão tomada, com seu contexto e consequências. Muitos times usam os dois: o RFC para deliberar, o ADR para selar o resultado.
Não, se você respeitar a imutabilidade. Um ADR aceito é um instantâneo datado: era verdadeiro naquele momento. Quando a realidade muda, você cria um novo ADR que substitui o antigo. O log inteiro continua válido como história — ninguém edita o passado.
Quem toma a decisão. Numa abordagem descentralizada (o “architecture advice process” do ThoughtWorks), qualquer pessoa pode tomar uma decisão desde que peça conselho a quem é afetado e a quem tem expertise — e registre o resultado num ADR. Não precisa ser um arquiteto único e centralizador.
Não há número certo. O sinal de saúde não é volume, é confiança: o time confia que as decisões que sustentam carga estão registradas? Cinco bons registros valem mais que cinquenta triviais que ninguém lê.
Comece pequeno. Abra um arquivo, escreva o ADR-0001, e deixe o próximo “por que isso é assim?” ter uma resposta. O resto é repetição.
Da decisão solta à operação previsível
Um funil que não depende de memória não acontece por acaso — ele é construído. A InCuca ajuda times de marketing e vendas a transformar conhecimento frágil, preso na cabeça de poucos, em uma operação de RevOps documentada, automatizada e pronta para a IA. Da atribuição ao lead scoring, do handoff entre marketing e vendas ao pricing: a gente estrutura as decisões que sustentam o seu funil e constrói a automação que as mantém vivas.
Quer parar de redecidir as mesmas coisas a cada trimestre? Vamos conversar →
Fontes e leitura adicional
Referências consultadas · acesso em junho/2026
- Michael Nygard. Documenting Architecture Decisions — o ensaio de 2011 que cunhou o termo.
- Martin Fowler. Architecture Decision Record (bliki).
- ADR GitHub organization. adr.github.io — definições, templates e tooling.
- MADR. Markdown Architectural/Any Decision Records e histórico de releases.
- Olaf Zimmermann. Architectural Decisions — The Making Of e Y-Statements.
- ThoughtWorks Technology Radar. Lightweight ADRs (Adopt) e Design System Decision Records.
- Red Hat. Why you should be using architecture decision records.
- GDS Way. Documenting architecture decisions.
- Thomas Vaillant. Log4brains — ferramenta de gestão e publicação de ADRs.
- Joel Parker Henderson. Coleção de templates e exemplos de ADR.
- Software Improvement Group. Using ADRs to guide your architecture choices.
- Hidekazu Konishi. ADRs: Templates and Operational Patterns.
