Você já ouviu alguém dizer: “IA vai substituir desenvolvedores, então eu deveria migrar para arquitetura”. Parece lógico, até perceber que arquitetura é exatamente o tipo de trabalho que a IA mais tem dificuldade: tomar decisões contextuais de trade-off em ambientes complexos e mutáveis. Essa é a premissa de abertura do livro Fundamentals of Software Architecture de Mark Richards e Neal Ford, e ela define o tom de todo o trabalho.
Este artigo cobre as ideias centrais do Capítulo 1: o que arquitetura de software realmente é, as 3 leis universais que governam toda decisão, e as 8 coisas esperadas de qualquer arquiteto, com título ou sem.
O que é Arquitetura de Software?
Arquitetura de software é definida por 4 dimensões:
| Dimensão | O que define | Analisada quando |
|---|---|---|
| Architecture Characteristics | Capacidades do sistema (-ilities) | Primeiro |
| Logical Components | Comportamento do sistema (domínio) | Segundo |
| Architecture Style | Molde estrutural de implementação | Depois das duas anteriores |
| Architecture Decisions | Regras e restrições de construção | Documenta tudo |
A ordem importa. Você começa com characteristics e components, depois escolhe um estilo, e documenta decisões ao longo do caminho. Pular etapas para escolher um estilo (como microservices) antes de entender o que o sistema realmente precisa é o caminho para o superdimensionamento.
Architecture Characteristics (-ilities)
Elas definem as capacidades de um sistema: no que ele deve ser bom. Performance, escalabilidade, segurança, testabilidade, observabilidade.
O livro evita o termo “requisitos não-funcionais” de propósito. Essa nomenclatura é auto-depreciativa (quem quer trabalhar em algo “não-funcional”?) e enganosa. Características arquiteturais são críticas para o sucesso, não preocupações secundárias.
O que caracteriza uma architectural characteristic?
Três critérios devem ser satisfeitos simultaneamente:
- É non-domain (não é uma feature de negócio)
- Influencia a estrutura (exige decisão estrutural, não apenas um ajuste de design)
- É crítico para o sucesso (se falhar, o sistema falhou)
Exemplo: segurança pode às vezes ser resolvida com escolhas de design (hashing, criptografia) em um monolito simples, então pode não ser uma characteristic estrutural. Mas escalabilidade não pode ser resolvida com design sozinho; exige distribuir o sistema, o que é uma mudança estrutural. Isso a torna uma architectural characteristic.
Implicit vs. Explicit
- Implicit: nunca aparece em documentos de requisitos, mas é essencial (disponibilidade, manutenibilidade). Nenhum product manager pede, mas o arquiteto precisa identificar.
- Explicit: aparece em requisitos ou instruções diretas (tempo de resposta abaixo de 200ms).
Trade-offs são inevitáveis
Cada característica adicionada aumenta a complexidade. Elas são sinérgicas: mudar uma impacta todas as outras. Melhorar segurança (mais criptografia) piora performance.
“Never strive for the best architecture; aim for the least worst architecture.”
Arquitetura é sobre minimizar o pior cenário, não maximizar todas as qualities de uma vez.
As 3 Leis da Arquitetura de Software
Richards e Ford originalmente queriam encontrar 10 ou 15 verdades universais. Encontraram apenas 2 na primeira edição, e descobriram uma terceira ao escrever a segunda. Essas 3 leis informam tudo mais no livro.
Primeira Lei: Tudo é trade-off
“Everything in software architecture is a trade-off.”
Toda decisão que um arquiteto toma deve considerar variáveis que mudam dependendo do contexto. Trade-offs são a essência da arquitetura.
Corolário 1: Se você acha que encontrou algo que não é um trade-off, provavelmente ainda não identificou o trade-off.
- Usar cache? Melhor performance, mas consistência eventual.
- Monolito? Simplicidade operacional, mas dificuldade de escalar times.
- Microservices? Escalabilidade de deploy, mas complexidade operacional absurda.
Corolário 2: Não é possível fazer análise de trade-offs uma vez e considerar encerrado.
Contextos mudam. O que funciona no projeto A pode ser catastrófico no projeto B. Times que tentam criar um padrão único (como “vamos sempre usar choreography”) descobrem que funciona às vezes e é desastroso outras.
Segunda Lei: O “porquê” é mais importante que o “como”
“Why is more important than how.”
Um arquiteto experiente consegue entender como funciona uma arquitetura que nunca viu. Mas entender por que decisões específicas foram tomadas exige conhecer o contexto: os trade-offs considerados, as restrições existentes, as alternativas rejeitadas.
É por isso que Architecture Decision Records (ADRs) importam. Sem documentar o “porquê”, você arrisca:
- Refazer decisões que já foram avaliadas e rejeitadas
- Quebrar algo que funcionava por um motivo que você não entende
Terceira Lei: A maioria das decisões não é binária
“Most architecture decisions aren’t binary but rather exist on a spectrum between extremes.”
Decisões raramente são “isso ou aquilo”. Elas existem em um espectro:
Onde você se posiciona depende do contexto. Isso conecta diretamente com a Primeira Lei: se tudo é trade-off, decisões são sobre onde no espectro você quer estar, não sobre escolher um extremo.
Como as 3 leis se conectam
- Tudo é trade-off (fundamento)
- Por isso o “porquê” importa (trade-offs explicam o contexto por trás de uma decisão)
- E por isso decisões são espectros (trade-offs raramente são absolutos)
Juntas, essas leis dizem: arquitetura é tomada de decisão contextual, contínua, sem resposta universal.
As 8 Expectativas de um Arquiteto de Software
Elas se aplicam independentemente de título, cargo ou descrição de job.
1. Tomar decisões de arquitetura
Guiar, não especificar. Decidir “usar um framework reativo para frontend” é arquitetural. Decidir “usar React” é técnico. A exceção: quando uma escolha específica de tecnologia é necessária para preservar uma characteristic como performance ou escalabilidade.
2. Analisar continuamente a arquitetura
Architecture vitality significa avaliar o quão viável continua sendo uma arquitetura definida há 3+ anos. A maioria dos arquitetos não dedica energia suficiente a isso, e o resultado é structural decay: mudanças de código que erodem silenciosamente características como performance e disponibilidade.
Além disso: se leva semanas para testar e meses para release, a arquitetura não é ágil, por mais limpo que o código pareça.
3. Manter-se atualizado com tendências
As decisões de arquiteto são de longo prazo e difíceis de reverter. Entender tendências (cloud, IA generativa, platform engineering) ajuda a fazer decisões que continuam relevantes.
4. Garantir conformidade com decisões
Se você decide que apenas as camadas Business e Services podem acessar o banco, e um desenvolvedor de UI contorna isso por performance, a arquitetura falha. Conformidade deve ser verificada continuamente, idealmente com fitness functions automatizadas.
5. Entender diversas tecnologias
Foque em amplitude, não profundidade. Conhecer prós e contras de 10 produtos de cache é mais valioso do que ser expert em 1. Ambientes modernos são heterogêneos.
6. Conhecer o domínio de negócio
Um arquiteto em banco que não entende termos financeiros perde credibilidade rápido. Os melhores arquitetos combinam conhecimento técnico amplo com forte conhecimento de domínio. Conseguem falar com executivos C-level na linguagem deles.
7. Ter habilidades interpessoais
“No matter what they tell you, it’s always a people problem.” (Gerald Weinberg)
Habilidades de liderança são pelo menos metade do que torna um arquiteto efetivo. O mercado está flooded de arquitetos; quem tem boas soft skills se destaca.
8. Navegar política organizacional
Quase toda decisão arquitetural será desafiada. Ao contrário de um desenvolvedor escolhendo um design pattern (sem precisar de aprovação), um arquiteto decidindo criar application silos enfrentará objeções de product owners, PMs, stakeholders e outros desenvolvedores. Habilidades de negociação não são opcionais.
A Grande Lição
Arquitetura, como arte, só pode ser entendida em contexto. Em 2002, microservices seriam inconcebivelmente caros (50 licenças Windows, 30 de app server, 50 de banco). Hoje são viáveis por causa de open source e DevOps. Todas as arquiteturas são produto do seu contexto.
Lembre-se disso. Não existe arquitetura universalmente “melhor”. Existe apenas a arquitetura que se encaixa nas suas restrições, no seu time, no seu prazo e nos seus trade-offs.
Este artigo é baseado no Capítulo 1 de Fundamentals of Software Architecture de Mark Richards e Neal Ford (2ª Edição, 2025).