Pular para o conteúdo principal

O que é Arquitetura de Software

Visão Geral​

Existem dezenas de definições de arquitetura de software na literatura, e a maioria é verdadeira e inútil ao mesmo tempo. "A estrutura de alto nível do sistema" descreve algo real e não ajuda ninguém a decidir se uma escolha específica é arquitetural.

A definição operacional deste material é outra:

Arquitetura é o conjunto de decisões cujo custo de reversão é alto.

Essa formulação, próxima da que Martin Fowler popularizou, tem uma propriedade que as outras não têm: é aplicável. Diante de qualquer escolha, você consegue perguntar quanto custaria desfazê-la em seis meses, com o sistema em produção e consumidores acoplados. Se a resposta for "muito", a decisão é arquitetural, e merece o cuidado correspondente.

O Problema​

A pergunta "isso é arquitetura?" aparece o tempo todo em times reais, e normalmente é respondida por proxy: é arquitetura se o arquiteto decidiu, ou se está no diagrama, ou se envolve mais de um serviço.

Nenhum desses proxies funciona.

A escolha do formato de identificador de uma entidade — inteiro sequencial, UUID, identificador natural — não aparece em diagrama nenhum, não envolve mais de um serviço, e frequentemente é feita por quem escreve a primeira migração. Também é uma das decisões mais caras de reverter que existem: muda o esquema, os índices, as chaves estrangeiras, os contratos de API, os dados históricos e todos os sistemas que armazenaram aquele identificador.

Enquanto isso, a escolha entre duas bibliotecas de serialização — que costuma render meia hora de debate — geralmente se troca numa tarde.

Usar a hierarquia ou o diagrama como critério faz o time gastar atenção arquitetural na segunda e nenhuma na primeira.

Conceitos Centrais​

Custo de reversão, não importância​

O critério não é o quão importante a decisão parece. É quanto custa desfazê-la depois que o sistema está em uso.

Esse custo tem componentes previsíveis: quantos módulos dependem da decisão, quantos sistemas externos a observam, quanto dado existe no formato antigo, e se existe caminho de migração incremental ou só uma virada de chave.

Arquitetura existe em todo sistema​

Todo sistema tem arquitetura, tenha alguém decidido ou não. As decisões de alto custo de reversão são tomadas de qualquer forma — a diferença é se foram tomadas deliberadamente ou por acidente de implementação.

"Não temos arquitetura" nunca é verdade. O que existe é arquitetura acidental: o resultado acumulado de decisões locais que ninguém avaliou pelo custo futuro.

O escopo é contextual​

O que é arquitetural depende do sistema. Numa aplicação com dez usuários internos, a escolha de banco de dados é facilmente reversível — há pouco dado, nenhum consumidor externo, e uma tarde de trabalho. Na mesma aplicação com oito anos e quarenta integrações, a mesma escolha virou irreversível na prática.

A decisão não mudou. O custo de reversão mudou. Por isso arquitetura é uma propriedade da relação entre a decisão e o contexto, não da decisão sozinha.

Arquitetura não é o diagrama​

O diagrama é uma representação, e uma parcial. Ele mostra estrutura estática e raramente mostra as decisões que mais custam: garantias de consistência, propriedade de dados, contratos de erro, semântica de retry.

Um sistema pode ter diagrama impecável e arquitetura ruim.

Modelo Mental​

Pense em arquitetura como o conjunto de portas que você fecha.

Cada decisão abre um caminho e fecha outros. Escolher consistência forte fecha a porta de operar durante partição de rede. Escolher um banco de documentos fecha a porta de consultas relacionais baratas. Escolher microsserviços fecha a porta de transações locais entre eles.

Decisões arquiteturais são aquelas cujas portas fechadas são caras de reabrir.

Isso leva direto a uma heurística prática: quando duas opções empatam em mérito, escolha a mais barata de abandonar. Você vai errar algumas dessas decisões — todo mundo erra — e o que separa um sistema que se recupera de um que não se recupera é quanto custa cada erro.

Por Que Isso Importa​

A definição por custo de reversão muda três coisas na prática.

Muda onde a atenção vai. Um time que aplica esse critério gasta duas horas decidindo o formato de identificador e dez minutos escolhendo biblioteca de log — que é o inverso do padrão comum, e é o correto.

Muda quem decide. Se arquitetura é definida por custo de reversão e não por cargo, então quem escreve a migração está tomando uma decisão arquitetural, e precisa saber disso. A alternativa — concentrar decisões num arquiteto que não está presente em cada escolha — não escala e não funciona.

Muda o que se documenta. Registra-se o porquê das decisões caras de reverter, porque são as que alguém vai querer reavaliar quando o contexto mudar, e as que não podem ser redescobertas experimentalmente.

Sem esse critério, discussões arquiteturais viram disputa sobre o que "conta" como arquitetura, que é uma conversa sem saída porque não tem critério.

Erros Comuns​

Confundir arquitetura com tecnologia. "Nossa arquitetura é Kubernetes com Kafka" descreve escolhas de infraestrutura, não arquitetura. As decisões arquiteturais estão em como as fronteiras foram desenhadas e que garantias existem entre elas — coisas que sobrevivem à troca de Kafka por outra coisa.

Tratar arquitetura como fase. Arquitetura não acontece antes do desenvolvimento e termina. Decisões de alto custo de reversão continuam sendo tomadas no ano três, e frequentemente por quem não se considera arquiteto.

Presumir que decisão difícil de tomar é decisão difícil de reverter. São independentes. Escolher entre dois provedores de nuvem é uma decisão penosa de tomar e cara de reverter. Escolher o nome de um campo público de API é uma decisão trivial de tomar e cara de reverter. A segunda recebe menos atenção do que merece precisamente por ser fácil.

Achar que decisão arquitetural precisa ser grande. Muitas são pequenas em esforço e enormes em consequência: o formato de um identificador, a semântica de um campo nulo, se um endpoint é idempotente.

Adiar decisões achando que adiar é grátis. Adiar tem custo: o sistema continua sendo construído sobre a ausência da decisão, e frequentemente a decisão acaba sendo tomada por omissão. Adiar é útil quando compra informação relevante — não quando só empurra a escolha para quem tiver menos contexto.

Exemplo Real​

Um sistema de assinaturas precisa registrar o momento de cada cobrança. Duas opções aparecem na revisão de código.

Opção A — armazenar em UTC e converter na apresentação. Opção B — armazenar no fuso do cliente.

Discutido como detalhe de implementação, o debate se resolve por preferência e demora quinze minutos.

Avaliado por custo de reversão: qual das duas é mais cara de desfazer com dois anos de dados? A opção B, com folga — reverter exige reinterpretar cada registro histórico à luz do fuso vigente naquele cliente naquela data, incluindo mudanças de horário de verão que já ocorreram. Parte da informação necessária pode nem ter sido armazenada.

A opção A não é obviamente melhor em toda dimensão — relatórios por dia local ficam mais trabalhosos. Mas ela é drasticamente mais barata de abandonar, e é essa assimetria que decide o caso.

O valor do critério aqui não foi apontar a resposta. Foi transformar uma discussão de preferência em uma pergunta com resposta verificável.

Conceitos Relacionados​

Exercício Prático​

Pegue um sistema em que você trabalha. Liste dez decisões tomadas nos últimos seis meses — qualquer decisão, de escolha de biblioteca a nome de campo.

Para cada uma, estime em dias de trabalho quanto custaria revertê-la hoje.

Duas perguntas sobre o resultado: quantas das cinco mais caras receberam discussão explícita quando foram tomadas? E quantas foram tomadas por alguém que sabia que estava decidindo algo de alto custo?

A distância entre essas duas respostas é a lacuna arquitetural do time.

Perguntas de Entrevista​

  • Como você decide se uma escolha é arquitetural?
  • Cite uma decisão pequena em esforço e grande em consequência que você já tomou.
  • Um sistema pode ter uma boa arquitetura sem documentação? E documentação impecável com arquitetura ruim?

Para Aprofundar​

  • Fowler, Martin. Who Needs an Architect? IEEE Software, 2003 — origem da formulação por custo de mudança.
  • Ford, Neal; Parsons, Rebecca; Kua, Patrick. Building Evolutionary Architectures. O'Reilly, 2017 — arquitetura como propriedade que evolui.
  • Bass, Len; Clements, Paul; Kazman, Rick. Software Architecture in Practice. 4ª ed., Addison-Wesley, 2021 — a definição estrutural clássica, útil como contraponto à adotada aqui.