Pular para o conteúdo principal

Evolução da Arquitetura

Visão Geral​

Nenhuma arquitetura é final. Contexto de negócio muda, volume muda, times mudam, tecnologia muda, e o que era adequado deixa de ser.

A questão não é se a arquitetura vai mudar. É se ela vai mudar por decisão ou por acúmulo — e a segunda é o caminho padrão quando ninguém escolhe a primeira.

O Problema​

Arquiteturas são tratadas como se tivessem um estado correto a atingir. O projeto é feito, o sistema é construído, e a partir daí mudanças arquiteturais são vistas como correção de erro.

Isso produz duas patologias.

A primeira é a resistência à mudança. Como mudar a arquitetura significaria admitir que a original estava errada, a estrutura é preservada muito além de sua validade, e o sistema acumula contornos.

A segunda é a reescrita. Quando a distância entre a arquitetura e a necessidade fica grande demais para ignorar, a proposta é recomeçar — que é a forma mais cara e arriscada de evoluir, e a que mais falha.

O caminho que funciona é o intermediário e o menos praticado: mudança contínua e incremental, decidida a partir de sinais observados.

Conceitos Centrais​

A decisão estava certa; o contexto mudou​

A distinção que desarma a resistência.

Uma arquitetura escolhida para seis engenheiros e mil usuários não estava errada quando foi escolhida. Ela deixou de servir quando o time chegou a sessenta e os usuários a um milhão.

Enquadrar a mudança como correção de erro torna a conversa política. Enquadrar como resposta a mudança de contexto torna a conversa técnica — e é essa a formulação correta, desde que o registro das decisões exista para sustentá-la.

Sinais de que precisa mudar​

Sinais observáveis, e não impressões:

  • Mudanças simples tocam número crescente de módulos.
  • O tempo entre decidir uma funcionalidade e entregá-la cresce sem que o escopo cresça.
  • Incidentes se repetem no mesmo ponto estrutural.
  • Um componente concentra os conflitos de merge do time.
  • A operação exige cada vez mais pessoas para o mesmo volume.
  • Uma característica arquitetural dirigente deixou de ser atendida e ninguém consegue apontar uma correção local.

O último é o mais decisivo, e o que exige ter as características declaradas para ser percebido.

Projetar para ser mudado​

A propriedade que importa não é adivinhar o futuro — ninguém adivinha. É que mudar seja possível sem reescrever.

Três coisas produzem isso, e as três já foram vistas neste nível:

Fronteiras impostas, para que uma mudança possa ser contida. Ver arquitetura vs. implementação.

Decisões registradas, para que se saiba o que se está mudando e por quê.

Verificação automatizada das propriedades que importam, para que a degradação seja visível antes de ser estrutural. É a ideia de fitness function, que reaparece no Nível 07.

Evolução incremental vence reescrita​

A reescrita falha por razões estruturais, não por má execução: o sistema antigo continua evoluindo durante ela, as regras não documentadas só aparecem quando o novo erra em produção, e o valor só chega no fim — quando o orçamento acabou.

Mudança incremental entrega valor antes de estar completa e pode ser revertida em qualquer ponto. É o assunto de modernização de legado, e o padrão principal é o strangler fig.

Por Que Isso Importa​

Porque a alternativa acontece sozinha. Uma arquitetura que não é evoluída deliberadamente evolui por acúmulo de contornos — que é evolução também, só que sem direção.

Porque muda o que se otimiza no projeto inicial. Se a arquitetura vai mudar, a propriedade valiosa não é estar certa — é ser barata de mudar. Isso desloca a prioridade para fronteiras e reversibilidade, e para longe de completude.

Porque torna a conversa possível. "O contexto mudou, e estes são os sinais" é uma proposta discutível. "A arquitetura está errada" é uma acusação.

Erros Comuns​

Tratar a arquitetura como definitiva. Produz resistência e, no limite, reescrita.

Propor reescrita como primeira resposta. É a opção mais cara e a que mais falha. Merece ser a última considerada, não a primeira.

Evoluir sem sinal. Mudar arquitetura por moda, por preferência ou por desconforto estético é custo sem retorno. Os sinais acima são o critério.

Não medir. Sem instrumentação, a degradação é percebida tarde e como sensação, não como fato — e sensação não sustenta uma proposta de investimento.

Mudar tudo de uma vez. Mesmo quando a direção está certa, a mudança precisa ser fatiada em passos que entregam valor e podem ser revertidos.

Confundir evolução com acumular contorno. Cada contorno individual é barato; o conjunto é o que impede a evolução real.

Exemplo Real​

Um sistema de agendamento nasceu como monolito com banco único, para um time de cinco pessoas. A escolha estava correta e foi registrada com essa razão.

Ao longo de quatro anos: o time chegou a trinta pessoas em quatro squads; o volume cresceu quarenta vezes; e um dos squads passou a atender clientes corporativos com requisito de disponibilidade contratual que os outros não tinham.

Os sinais apareceram em ordem. Primeiro, conflitos de merge concentrados em dois módulos. Depois, o tempo de entrega crescendo sem crescimento de escopo. Por fim, o squad corporativo sem conseguir atender ao SLA porque uma implantação de outro squad derrubava tudo.

O terceiro sinal é o que decidiu: uma característica dirigente — disponibilidade para um segmento — deixou de ser atendida, e não havia correção local.

A resposta não foi migrar para microsserviços. Foi extrair um serviço: o do fluxo corporativo, que tinha requisito distinto e fronteira já estável no histórico de commits.

Dezoito meses depois, um segundo serviço foi extraído pelo mesmo critério. Os outros dois squads continuam no monolito, e não há plano de tirá-los — nenhum sinal indica que deveriam sair.

O que essa arquitetura tem de bom não é a forma. É que a forma mudou duas vezes, cada vez por um sinal específico, e pode mudar de novo.

Conceitos Relacionados​

Exercício Prático​

Liste as decisões arquiteturais principais do seu sistema e, ao lado de cada uma, o contexto em que foi tomada: tamanho do time, volume, restrições.

Compare com o contexto de hoje.

Onde a distância for grande, verifique se há sinal observável de que a decisão parou de servir — ou se ela continua adequada apesar da mudança de contexto. As duas respostas acontecem, e distingui-las é o exercício.

Perguntas de Entrevista​

  • Como você sabe que uma arquitetura precisa mudar?
  • Por que reescritas completas falham com tanta frequência?
  • O que torna uma arquitetura fácil de evoluir?

Para Aprofundar​

  • Ford, Neal; Parsons, Rebecca; Kua, Patrick. Building Evolutionary Architectures. O'Reilly, 2017.
  • Feathers, Michael. Working Effectively with Legacy Code. Prentice Hall, 2004.
  • Fowler, Martin. StranglerFigApplication, 2004.