Arquitetura de Software explicada: as decisões caras de mudar
Uma definição prática, popularizada por Martin Fowler: arquitetura é aquilo que as pessoas experientes de um time consideram difícil de mudar. Não é diagrama bonito nem lista de tecnologias — é o conjunto de decisões estruturais que condicionam tudo o que vem depois.
Qual a diferença entre arquitetura e programação
Programação responde 'como faço este comportamento funcionar'. Arquitetura responde 'como organizo o sistema para que dez comportamentos futuros continuem possíveis'. A primeira decisão é local e reversível; a segunda é global e cara.
Exemplo cotidiano: numa casa, mudar a cor da parede é programação; mudar a posição das paredes estruturais é arquitetura. Ambas são necessárias, mas exigem tempos de decisão diferentes.
Quando devo pensar na arquitetura do meu sistema?
Antes de escrever a primeira funcionalidade que dependa de uma decisão irreversível: modelo de dados, estratégia de identidade e permissão, isolamento entre clientes, integração com sistemas externos e política de dados sensíveis.
O oposto também é um erro. Projetar para uma escala que nunca chegou consome orçamento e adiciona complexidade permanente. A regra prática é arquitetar para o próximo patamar realista, mantendo fronteiras que permitam cortar o sistema depois, se preciso.
- Decida cedo: identidade, autorização, modelo de dados, multi-tenant, auditoria.
- Adie: escolha de fila, cache distribuído, separação em serviços.
- Deixe rastro: fronteiras internas claras tornam a separação futura barata.
Monólito ou microsserviços: qual faz mais sentido?
Sam Newman é enfático ao tratar microsserviços como uma escolha organizacional antes de ser técnica: eles resolvem o problema de vários times precisarem entregar de forma independente. Se existe um time só, esse benefício não se aplica — sobra o custo.
Um monólito bem modularizado, com fronteiras internas explícitas, entrega quase toda a clareza dos microsserviços sem o custo operacional de rede, deploy distribuído, consistência eventual e observabilidade fragmentada.
- Monólito modular: menor custo operacional, transação simples, deploy único.
- Microsserviços: independência de times, escala seletiva, isolamento de falha.
- Custo dos microsserviços: latência de rede, dados distribuídos, complexidade de depuração.
- Caminho comum e saudável: começar modular e extrair serviços quando a dor aparecer.
Arquitetura influencia segurança e desempenho?
Diretamente. Onde a autorização é aplicada define se um erro de tela vira vazamento de dados. Onde o dado sensível trafega define o tamanho da superfície de ataque. Como as consultas são modeladas define se o sistema aguenta o décimo cliente ou trava no terceiro.
Len Bass e coautores tratam esses aspectos como atributos de qualidade: desempenho, segurança, disponibilidade e modificabilidade não são recursos que se acrescentam depois — são propriedades que emergem da estrutura escolhida.
O papel do arquiteto: reduzir arrependimento
Boas decisões arquiteturais são as que preservam opções. Eric Evans, ao propor o design orientado a domínio, defende que a estrutura do software reflita a linguagem e as fronteiras do negócio — assim, quando o negócio muda, o impacto fica contido em uma região do sistema.
Nem todo projeto precisa de uma pessoa com o cargo de arquiteto. Todo projeto precisa que alguém assuma essas decisões conscientemente e as registre.
Em resumo
Arquitetura é gestão de arrependimento futuro. Decida cedo o que é caro mudar, adie o resto e mantenha fronteiras que permitam evoluir sem reescrever.
Casos de uso
SaaS multiempresa
Isolamento por organização precisa estar no banco e nas políticas de acesso, não apenas na interface.
Integração com ERP legado
Camada anticorrupção evita que o modelo do sistema externo contamine o domínio interno.
Pico sazonal de tráfego
Separar leitura pesada de escrita costuma render mais que fragmentar o sistema em serviços.
Erros comuns
- Adotar microsserviços com um único time e sem automação de infraestrutura.
- Deixar a autorização apenas na camada de interface.
- Modelar o banco espelhando telas em vez do domínio.
- Escolher tecnologia por moda e não por restrição real do problema.
- Não registrar decisões: seis meses depois ninguém lembra o motivo.
Boas práticas
- Escrever registros curtos de decisão arquitetural (contexto, opção, consequência).
- Manter fronteiras de módulo explícitas dentro do monólito.
- Aplicar autorização no ponto mais próximo do dado.
- Definir atributos de qualidade com números (latência, disponibilidade, retenção).
- Revisar a arquitetura a cada marco relevante do produto.
Livros recomendados
Software Architecture in Practice — Len Bass, Paul Clements e Rick Kazman
Formaliza atributos de qualidade e como a estrutura os viabiliza.
Building Microservices — Sam Newman
Mostra benefícios e, principalmente, os custos reais de distribuir um sistema.
Domain-Driven Design — Eric Evans
Ensina a alinhar fronteiras de software às fronteiras do negócio.
Patterns of Enterprise Application Architecture — Martin Fowler
Catálogo de padrões recorrentes em aplicações corporativas.
Para aprofundar
Perguntas frequentes
- O que é Arquitetura de Software?
- É o conjunto de decisões estruturais difíceis de reverter: fronteiras, modelo de dados, comunicação entre partes e atributos de qualidade exigidos.
- Quando devo pensar na arquitetura do meu sistema?
- Antes das primeiras funcionalidades que dependam de decisões irreversíveis, como identidade, permissões e modelo de dados.
- Toda aplicação precisa de um arquiteto de software?
- Nem sempre precisa do cargo, mas sempre precisa que alguém assuma e registre as decisões estruturais.
- Monólito ou microsserviços: qual faz mais sentido?
- Com um time só, monólito modular quase sempre vence. Microsserviços compensam quando vários times precisam entregar de forma independente.
- Arquitetura influencia a segurança e o desempenho?
- Sim. Onde a autorização é aplicada e como os dados são modelados determinam grande parte do risco e da capacidade de escalar.
- Quais erros de arquitetura são mais comuns em projetos iniciantes?
- Distribuir cedo demais, modelar o banco a partir das telas, deixar regras de acesso na interface e não documentar decisões.
Referências
- Martin Fowler — arquitetura como o conjunto de decisões difíceis de mudar
- Sam Newman, Building Microservices — microsserviços como decisão organizacional
- Len Bass et al., Software Architecture in Practice — atributos de qualidade
- Eric Evans, Domain-Driven Design — linguagem ubíqua e contextos delimitados
Conteúdo original da equipe i9 Conecty. Conceitos clássicos são explicados com palavras próprias e creditados aos seus autores.
Continue lendo
Engenharia
Engenharia de Software explicada: muito além de escrever código
Produto
Tenho uma ideia de sistema. E agora? O caminho da ideia ao software
Inteligência Artificial
Posso construir meu projeto inteiro usando IA? Uma resposta honesta
Segurança