Boa arquitetura sobrevive ao requisito que ninguém previu

Há uns anos apresentei uma arquitetura que a diretoria aplaudiu. Quatro serviços, fronteiras limpas por domínio, cada caixa com uma responsabilidade só, as setas apontando todas para o lado certo. No slide, era evidente que aquilo estava correto. Levei meses para entender que “evidente no slide” e “correto em produção” são réguas diferentes, e que eu tinha medido pela errada.

O requisito que derrubou o desenho era quase ofensivo de simples: uma tela mostrando, juntos, dados que eu havia espalhado por quatro serviços. O que no diagrama era uma fronteira elegante virou, no código, um join distribuído, consistência eventual e uma tela que de vez em quando mentia para o usuário. A arquitetura era bonita. Ela só não sobrevivia ao primeiro requisito que ninguém tinha previsto.

A régua é o dia seguinte, não o diagrama

Um diagrama é uma foto tirada no melhor ângulo. Ele mostra o sistema respondendo exatamente às perguntas que você já sabia fazer. O requisito imprevisto é a régua honesta porque chega de um ângulo que a foto não cobria, e aí você descobre se construiu uma estrutura ou um cenário.

Passei a julgar decisão de arquitetura por uma pergunta só: quando o requisito que eu não imaginei chegar, isto aqui dobra ou racha? Fronteira que dobra é barata de mover. Fronteira bonita costuma ser cara de mover, porque a beleza no diagrama quase sempre vem de uma simetria que o mundo real não tem obrigação de respeitar.

Fronteira se paga na hora de movê-la, não na hora de desenhá-la.

A que envelheceu bem foi a mais feia

No projeto seguinte fiz o oposto e me senti covarde. Um monólito modular, um banco só, um módulo dono de cada escrita, costuras internas claras e nenhuma rede entre elas. No diagrama era uma caixa grande e sem graça. Ninguém aplaude uma caixa grande.

Aí os requisitos imprevistos começaram a chegar, como sempre chegam. Um relatório novo cruzando três módulos: uma query. Um fluxo que precisava de dois passos numa transação: um commit. Cada mudança que teria sido uma saga distribuída no desenho bonito foi uma chamada de função no desenho feio. A caixa sem graça dobrou toda vez. Envelheceu bem justamente porque não tinha comprado nenhuma fronteira antes de ter dinheiro para pagá-la.

O meio-termo: comprei tempo, não permanência

Nem toda decisão cai limpa num dos lados. Numa integração de pagamento coloquei uma interface fina na frente do provedor, prevendo troca. Quando a troca veio, a metade da abstração que era genérica de verdade segurou, e a metade que tinha vazado conceito específico do provedor antigo precisou ser reescrita. Não foi vitória nem desastre. A fronteira dobrou pela metade: pagou o custo de existir, mas não a promessa de permanência que eu tinha vendido para mim mesmo.

Guardo essa como a mais útil das três, porque desarma a leitura preguiçosa da régua. Sobreviver ao requisito não é acertar o futuro. É deixar barato o dia em que você erra.

O que fica pelo caminho

O que a régua joga fora é a vaidade do diagrama. O desenho que impressiona na sala existe para uma plateia que não vai manter o código. O requisito imprevisto chega para quem fica. Entre agradar a plateia e servir a quem fica, arquitetura é a segunda coisa, sempre.

Diagrama bonito ganha a reunião. Ele não segura a empresa quando chega o requisito que ninguém previu. E sempre chega.