Reversibilidade como objetivo de arquitetura

Eu não tento tomar a decisão certa em toda questão de arquitetura. Tento tomar a decisão mais barata de reverter quando se revelar errada. São objetivos diferentes, e o segundo já rendeu muito mais dinheiro para meus clientes do que o primeiro.

Acertar exige informação que você ainda não tem: como o produto vai evoluir, quantos usuários vão aparecer, quais integrações vão importar. Ser reversível só exige disciplina que você pode aplicar hoje. E quando reverter é barato, errar deixa de ser caro, o que significa que você pode decidir mais rápido e com menos debate.

Dois tipos de decisão

Algumas decisões são portas que abrem para os dois lados. Qual biblioteca de log. Como estruturar uma pasta. Se um job roda a cada cinco ou a cada dez minutos. Se errar, você troca, e ninguém fora do time percebe.

Outras decisões são portas de mão única. O motor do banco principal depois que há dados nele. O modelo de multi-tenancy. O formato de identificador exposto em URLs públicas. O schema de evento contra o qual três parceiros externos já se integraram. A linguagem do núcleo. Errar nessas custa um projeto de migração medido em trimestres.

O erro que a maioria dos times comete é tratar os dois tipos com o mesmo cuidado. Debatem a biblioteca de log por uma semana e escolhem o modelo de tenancy numa tarde porque 'dá para mudar depois'. A alocação certa é o inverso. Gaste o tempo de reunião nas portas de mão única. Decida as portas de dois lados em dez minutos e siga em frente.

Transformando portas de mão única em portas de dois lados

Esse é o trabalho de arquitetura de verdade: pegar uma decisão que seria cara de reverter e envolvê-la de forma que a reversão se torne possível. Não de graça, mas possível, dentro de um ou dois sprints.

O motor do banco vira reversível quando nenhum módulo fora da camada de dados sabe qual motor é: nada de SQL bruto vazando para o código de negócio, nada de tipos específicos do motor no domínio, e uma suíte de testes que roda contra um segundo motor de vez em quando, mesmo que só uma parte. O formato de identificador público vira reversível quando é opaco para os consumidores desde o primeiro dia, para você trocar de inteiros para ULIDs atrás de uma tabela de mapeamento sem ninguém notar. O broker de mensagens vira reversível quando produtores e consumidores conversam com uma interface interna fina que tem uma segunda implementação real, mesmo que seja só em memória para testes.

Nada disso é exótico. São as mesmas técnicas que as pessoas chamam de 'clean architecture' e depois abandonam sob pressão de prazo. O enquadramento que as mantém vivas é a pergunta: 'se essa escolha estiver errada, quanto custa descobrir?'

O orçamento de reversibilidade

Reversibilidade não é de graça, e fingir que é foi como times acabaram com camadas de abstração em cima de tudo. Cada costura que você adiciona custa alguma indireção, algum teste, alguma carga cognitiva. Então eu gasto isso de propósito.

Faço três perguntas sobre cada decisão. Qual a probabilidade de aprendermos algo no próximo ano que mudaria isso? Quanto custa reverter se não prepararmos nada? E quanto custa a preparação em si? Se a probabilidade é baixa e o custo de reversão é baixo, não faça nada. Se o custo de reversão é alto e a preparação é barata, prepare. Se os dois são altos, essa é a decisão que merece uma semana de análise de verdade, um ADR escrito e provavelmente um protótipo.

Lock-in de fornecedor tem linha própria. Todo serviço gerenciado que armazena seus dados ou define seu fluxo de trabalho ganha um caminho de exportação documentado antes da primeira escrita em produção. Não um plano completo de migração, só a prova de que os dados conseguem sair. Já vi times reféns de uma mudança de preço porque nunca conferiram.

Como isso aparece numa revisão

Quando reviso um sistema, listo suas portas de mão única em uma única página. Geralmente são menos de dez. Para cada uma, anoto se ainda é reversível, a que custo, e o que dispararia a reversão. Essa página diz mais para a liderança sobre o risco real deles do que qualquer diagrama de dependências.

Os sistemas que envelhecem bem não são os que acertaram todas as escolhas. São aqueles em que as escolhas erradas puderam ser desfeitas antes de virarem estruturais. Projete para isso. Acertar é bônus.