Decisões de arquitetura são tomadas com informação incompleta. Fingir que não são produz documentos que soam confiantes e sistemas que não conseguem se adaptar. Pela minha experiência, a maior parte dessa incerteza não vem da tecnologia. Vem de não entender o problema bem o suficiente antes de começar o design.
O problema
Quando um caso de uso de negócio chega no time, o reflexo é sair resolvendo. Em poucos minutos já tem gente falando de endpoint, de tabela e de qual serviço deveria ser dono de quê. O que fica para trás é o próprio problema: quem é o usuário, do que ele precisa e se o caso de uso, do jeito que foi escrito, é viável.
Um caso de uso pode chegar de formas bem diferentes. Pode estar bem pensado e pronto para ser construído. Pode ser a linha de raciocínio do product manager rumo a uma solução que não resolve bem o problema. Ou pode carregar muito mais complexidade do que a coisa simples que tenta resolver. Cada situação pede uma resposta diferente, e não dá para distinguir uma da outra sem cavar.
Além disso, os times continuam precisando tomar decisões técnicas com consequências sérias antes de ter bons dados sobre escala, rumo do produto, contratações, custo e maturidade operacional.
Onde os times costumam errar
O primeiro erro é pular do caso de uso direto para a implementação sem perguntar se o caso de uso está certo. O design que vem depois pode ser excelente e mesmo assim resolver o problema errado, ou resolver um problema simples de um jeito complicado.
O segundo erro aparece quando o problema já está claro: ou o time projeta demais para um futuro imaginado, ou projeta de menos porque o sistema atual ainda funciona.
Princípios
- Entenda o problema antes de desenhar a solução.
- Questione o caso de uso, inclusive o raciocínio por trás dele.
- Declare as restrições antes das preferências.
- Separe as decisões reversíveis das irreversíveis.
- Otimize para o próximo momento em que você vai aprender algo.
- Registre as opções descartadas.
- Deixe visível quanto custa estar errado.
Modelo de decisão
O fluxograma tem duas etapas. A primeira decide se vale a pena resolver o problema do jeito que ele chegou. A segunda decide como resolver e continua conferindo essa decisão depois da entrega.
O caso de uso chega
Eu começo aqui, antes de o trabalho chegar formalmente até mim. Quando o ticket é atribuído, o time já está pensando na implementação, e qualquer pergunta sobre o caso de uso começa a soar como atraso.
Entenda o problema
Quem é o usuário e o que ele está tentando fazer? O objetivo é descrever o problema em palavras simples, sem falar de endpoint, tabela ou serviço.
Explore alternativas
Procure outros caminhos para chegar ao mesmo resultado. O fluxo proposto muitas vezes é o caminho que uma pessoa imaginou até uma solução, e outro caminho pode ser mais simples.
O caso de uso faz sentido?
Quatro perguntas decidem:
- É viável do jeito que foi escrito.
- Resolve o problema real.
- A complexidade é proporcional ao problema.
- Bate com a intenção real por trás do pedido.
Problema de design de negócio
Se alguma dessas perguntas falhar, o problema está no design de negócio, não na arquitetura. Leve de volta ao produto com o que você encontrou e recomece quando o caso de uso revisado voltar. Nenhum trabalho técnico começa por esse caminho.
Qual é o alcance da decisão?
Com o caso de uso pronto para seguir, a próxima pergunta é até onde a decisão chega. A resposta define o documento.
Escreva uma RFC
A RFC serve para estabelecer arquitetura num ecossistema grande. A decisão afeta vários times, serviços ou consumidores, molda o que eles usam e precisa da opinião deles antes de alguém se comprometer com ela.
Escreva um ADR
O ADR serve para algo construído do zero, como um serviço novo ou uma feature nova, quando a mudança não quebra nada que já existe. Ele registra o contexto, a decisão e as opções que eu descartei, para que o raciocínio continue lá quando alguém perguntar depois.
Enquadre a decisão
Seja qual for o documento, a decisão cabe em uma página e registra oito coisas: contexto, restrições, opções, tradeoffs, risco, reversibilidade, os gatilhos que obrigariam a revisitá-la e o responsável.
Compare e decida
Compare duas opções sérias e uma descartada, e defina o primeiro ponto de rollback antes de se comprometer.
Entregue e observe
A decisão não termina na entrega. Espere o primeiro sinal de produção antes de dar o assunto por encerrado.
A decisão continua de pé?
Revise a decisão contra esse sinal e contra os gatilhos registrados no enquadramento. Se um gatilho foi acionado, volte a enquadrar a decisão com o que você aprendeu. Se não, a decisão continua até a próxima data de revisão ou gatilho.
Padrões práticos
Mantenha os documentos curtos, diga as suposições com todas as letras e, nas decisões com muita incerteza, anote uma data de revisão ou a condição que obriga a revisitar o assunto.
Tradeoffs
Questionar um caso de uso leva tempo, e pode soar como atrito para um product manager que já tem um plano. Pular essa etapa costuma sair mais caro, porque a conta chega depois, em forma de retrabalho em algo que não deveria ter sido construído daquele jeito.
O mesmo equilíbrio vale para os documentos. Um processo de decisão pesado pode travar o time, e um leve demais pode esconder tradeoffs importantes. Uma RFC para uma mudança dentro de um único serviço é burocracia. Um ADR para uma mudança que redesenha um ecossistema inteiro é pouco.
Fluxo de exemplo
- Antes de o caso de uso ser entregue formalmente, leia e converse com quem escreveu sobre o usuário e o problema.
- Explore pelo menos um outro caminho para chegar ao mesmo resultado.
- Decida se é um problema de design de negócio ou se está pronto para seguir. Se for um problema de design, leve de volta ao produto antes de começar qualquer trabalho técnico.
- Escolha o formato: RFC se a decisão molda o ecossistema como um todo, ADR se é um serviço novo ou uma feature que não quebra nada.
- Escreva o enquadramento da decisão em uma página, compare duas opções sérias e uma descartada e defina o primeiro ponto de rollback.
- Revise a decisão quando chegar o primeiro sinal de produção.
Checklist
- O usuário e o problema estão descritos em palavras simples.
- O caso de uso foi questionado e alternativas foram consideradas.
- Está claro se é um problema de design de negócio ou se está pronto para seguir.
- O formato combina com o alcance da decisão: RFC ou ADR.
- As restrições estão explícitas.
- A reversibilidade está classificada.
- As opções descartadas têm nome.
- O primeiro sinal de produção está definido.
- A decisão tem um responsável com nome.
Guias relacionados
- Como desenhar fronteiras de backend que aguentam a pressão de produção
- Práticas de teste e entrega que protegem o ritmo do time
Leve isto para o seu time
Este tema funciona bem como treinamento para times que precisam melhorar as revisões de arquitetura, criar uma prática de ADRs e RFCs que funcione ou aprender a questionar casos de uso antes de construí-los.