Arquitetura Evolutiva
Visão Geral
Nenhuma arquitetura permanece correta. As premissas que a produziram — volume, time, mercado, regulação, tecnologia — mudam, e o desenho que era adequado deixa de ser.
A resposta convencional é planejar melhor: prever mais, projetar mais flexível, antecipar. Ela falha porque as mudanças relevantes são justamente as que não foram previstas.
A alternativa é diferente:
não desenhar para todas as mudanças possíveis
e sim desenhar para que mudar seja barato, e proteger
as características que não podem se perder no caminho
Ver evolução da arquitetura para o conceito; aqui o foco é o que a liderança faz para que a evolução aconteça de forma guiada em vez de por deriva.
Problema
Sem mecanismo, a arquitetura muda por deriva:
cada decisão local é razoável
o somatório não é
ninguém decidiu que as fronteiras erodiriam
elas erodiram
O padrão é o mesmo descrito em velocidade vs. qualidade: decisões individuais corretas produzindo um resultado agregado que ninguém escolheu.
E há o erro oposto: congelar a arquitetura. Uma organização que trata mudança arquitetural como exceção acumula um desenho cada vez mais distante do problema atual, até que a única saída seja uma reescrita.
deriva muda sem decisão
congelada não muda, e a distância cresce
guiada muda com decisão, protegendo o que importa
Conceitos Centrais
Escolha as dimensões protegidas
Não é possível proteger tudo. A pergunta que estrutura o trabalho:
"quais características desta arquitetura não podem se
degradar, aconteça o que acontecer?"
exemplos de dimensão protegida
nenhum serviço acessa o banco de outro
o tempo de construção fica abaixo de 10 minutos
a latência p99 do checkout fica abaixo de 300 ms
nenhum segredo é gravado em código
todo serviço tem dono válido
Poucas — três a sete — e escolhidas por consequência. Cada uma vira um mecanismo de verificação. Ver funções de aptidão.
O que não está na lista pode se degradar, e isso é uma escolha consciente em vez de um descuido.
Mudança barata é a propriedade central
arquitetura evolutiva não é a que prevê mudanças
é a que torna mudanças baratas
O que torna mudança barata é conhecido e é o mesmo que torna software bom: fronteiras claras, acoplamento baixo, testes que dão confiança, implantação automatizada, e capacidade de reverter.
Nada disso é específico de arquitetura evolutiva — o que é específico é tratá-los como investimento em capacidade de mudar, e não como higiene.
Ver entrega contínua.
Reversibilidade vale mais que previsão
prever corretamente difícil, e frequentemente impossível
reverter barato alcançável, e cobre o caso de errar
Diante de incerteza, investir em capacidade de reverter rende mais que investir em análise. Uma decisão errada e reversível custa dias; a mesma decisão errada e irreversível custa o ciclo inteiro.
Isso muda o que se otimiza: em vez de acertar mais, errar mais barato.
Mudança incremental, sempre
grande e rara risco concentrado, difícil de reverter,
aprendizado tardio
pequena e
frequente risco distribuído, reversível, aprendizado
contínuo
Isso vale para arquitetura tanto quanto para código. Uma migração feita em fatias, cada uma reversível, é mais lenta em soma e muito mais segura — e permite que o plano sobreviva a interrupções. Ver roadmaps técnicos.
Deixe caminhos abertos onde a incerteza é alta
onde o futuro é conhecido otimize
onde é incerto preserve a opção, se for barato
Preservar opção tem custo, e ele precisa ser pequeno para valer. Ver simplicidade vs. flexibilidade — a assimetria é a mesma: comprar opcionalidade cara para um futuro incerto raramente se paga.
O que se paga quase sempre: isolar a dependência incerta num lugar identificável, sem generalizar.
Evolução exige medir o estado atual
Não é possível guiar o que não se observa:
acoplamento entre módulos, medido
tempo de construção e de implantação
frequência de mudança por área
áreas que mudam sempre juntas
tempo entre decisão e produção
A quarta linha é a mais reveladora: componentes que sempre mudam juntos indicam uma fronteira errada, e essa informação está no histórico do repositório sem que ninguém a extraia.
Nem tudo deve evoluir
evolui o que muda com o negócio
estável formatos publicados, contratos com externos,
fundações que muitos consomem
Uma organização que muda tudo continuamente impõe custo de acompanhamento a todos. Declarar o que é deliberadamente estável — e cuja mudança exige processo — é tão importante quanto tornar o resto maleável.
Modelo Mental
Proteja poucas dimensões, torne mudar barato, e reverta em vez de prever. Evolução guiada é o meio entre deriva e congelamento.
Quando Usar
- Em sistemas de vida longa, com incerteza sobre o futuro.
- Quando a arquitetura já derivou sem decisão.
- Quando o custo de mudar é o gargalo, e não a capacidade.
Quando Não Usar
Protegendo tudo — sem escolha, nenhuma dimensão é protegida de fato.
Como desculpa para não decidir — "vamos evoluir" não substitui escolher.
Em sistemas descartáveis — o investimento não se paga.
Sem medir o estado atual.
Tornando tudo maleável, inclusive contratos publicados.
Alternativas
- Arquitetura estável com revisão periódica — adequada em domínios que mudam pouco.
- Reescrita planejada — em alguns casos, aceitar que o sistema tem vida útil e planejar a substituição é mais barato que mantê-lo evolutivo.
- Congelar e isolar — manter o sistema como está, com fronteiras claras, e construir o novo ao lado. Ver estrangulamento.
A segunda é subestimada: nem todo sistema merece o investimento em evolutibilidade, e reconhecer isso é uma decisão econômica válida.
Trade-offs
| Evolutiva | Estável |
|---|---|
| Absorve mudança | Menos investimento |
| Custo contínuo de manter capacidade | Distância cresce |
| Exige medição | Simples |
| Muitas dimensões protegidas | Poucas |
|---|---|
| Mais garantias | Verificação sustentável |
| Custo de manter | Escolha explícita do que se degrada |
Modos de Falha
Deriva. Muda sem decisão, e o agregado não foi escolhido.
Congelamento. Distância cresce até a reescrita.
Proteção de tudo. Nenhuma dimensão de fato protegida.
Investir em previsão em vez de reversibilidade.
Mudança grande e rara. Risco concentrado.
Contratos publicados tratados como maleáveis.
Erros Comuns
Não escolher as dimensões a proteger.
Não medir acoplamento e frequência de mudança.
Confundir evolutiva com flexível — flexibilidade antecipada é o oposto.
Não usar o histórico do repositório como fonte de evidência.
Tratar "vamos evoluir" como decisão.
Exemplo Real
Uma empresa de serviços financeiros tinha um sistema de sete anos com um problema difícil de nomear: nada estava errado, e tudo era lento de mudar.
Uma medição sobre o histórico do repositório produziu a primeira evidência concreta:
tempo médio entre início e produção de uma mudança 18 dias
arquivos tocados por mudança, mediana 34
módulos tocados por mudança, mediana 5
pares de módulos que mudam juntos em > 60%
das vezes 11
tempo de construção 47 minutos
Os 11 pares que sempre mudavam juntos eram fronteiras erradas — módulos separados que na prática eram um só. E o tempo de construção de 47 minutos era o que tornava qualquer mudança cara, independentemente do tamanho.
O trabalho foi organizado como evolução guiada, não como reescrita:
Cinco dimensões protegidas, escolhidas por consequência e verificadas automaticamente:
tempo de construção abaixo de 10 minutos
nenhuma dependência cíclica entre módulos
nenhum módulo acessando dados de outro diretamente
cobertura de teste do domínio acima de 70%
tempo entre implantações abaixo de 3 dias
Cada uma virou verificação na esteira, introduzida em modo de aviso e depois bloqueante. Ver funções de aptidão.
Fronteiras corrigidas por evidência. Os 11 pares que mudavam juntos foram avaliados: 7 foram fundidos, 3 tiveram a fronteira redesenhada, e 1 se mostrou uma coincidência de projeto.
Tempo de construção atacado primeiro, porque ele multiplicava o custo de todas as outras mudanças. De 47 para 8 minutos em seis semanas.
Mudança incremental como regra. Nenhuma alteração estrutural em bloco; tudo em fatias reversíveis, com o sistema funcionando ao fim de cada uma.
Medição contínua das cinco dimensões e das métricas de mudança, visível para todos.
Resultados após 16 meses:
tempo entre início e produção de 18 dias para 4
arquivos tocados por mudança de 34 para 11
módulos por mudança de 5 para 2
pares que mudam sempre juntos 1
tempo de construção 7 minutos
dimensões protegidas violadas 0 desde o bloqueio
Nenhuma reescrita. O sistema é o mesmo, com as mesmas responsabilidades — o que mudou foi o custo de alterá-lo.
O detalhe que a equipe destaca: a medição sobre o histórico do repositório foi o instrumento mais barato e mais informativo do projeto. Ela custou dois dias de trabalho, existia desde sempre, e ninguém a tinha extraído — e os 11 pares que mudavam juntos apontaram para as fronteiras erradas com uma precisão que nenhuma análise de desenho tinha alcançado.
Conceitos Relacionados
- Evolução da Arquitetura.
- Funções de Aptidão — o mecanismo.
- Medição de Resultados.
- Simplicidade vs. Flexibilidade.
Exercício Prático
Extraia do histórico do seu repositório os pares de módulos que mudam juntos em mais de 60% das vezes.
Cada par é uma fronteira candidata a estar errada — e essa informação existe há anos sem que alguém a tenha olhado.
Perguntas de Entrevista
- Por que investir em reversibilidade rende mais que investir em previsão?
- Por que proteger tudo significa não proteger nada?
- Como o histórico do repositório revela fronteiras erradas?
Para Aprofundar
- Ford, Neal et al. Building Evolutionary Architectures. 2ª ed. O'Reilly, 2022.
- Forsgren, Nicole et al. Accelerate. IT Revolution, 2018.
- Feathers, Michael. Working Effectively with Legacy Code. Prentice Hall, 2004.