Arquitetura de Software é o conjunto de decisões estruturais fundamentais que definem como um sistema é organizado, quais são seus componentes, como eles se relacionam e quais restrições e atributos de qualidade devem ser respeitados. Essas decisões são caras de reverter depois e determinam a viabilidade técnica, o custo e a evolução do software ao longo do tempo.
Segundo o Software Engineering Institute (SEI) da Carnegie Mellon, a arquitetura de um sistema é ‘o conjunto de estruturas necessárias para raciocinar sobre o sistema, compreendendo elementos de software, relações entre eles e propriedades de ambos’. Ou seja, arquitetura não é apenas o diagrama — é o conjunto de decisões que sustentam o sistema.
Componentes principais
- Elementos: serviços, módulos, camadas, bancos de dados, filas, caches.
- Conexões: chamadas síncronas (HTTP, gRPC), assíncronas (eventos, filas), integrações com sistemas externos.
- Restrições: tecnologias obrigatórias, compliance (LGPD, PCI-DSS), orçamento, prazo.
- Atributos de qualidade: performance, escalabilidade, segurança, disponibilidade, manutenibilidade.
Padrões arquiteturais mais comuns
- Monolítico: aplicação única, deploy único. Simples e barata para começar.
- Microsserviços: serviços pequenos e independentes, cada um com seu banco. Escalabilidade e resiliência maiores, complexidade operacional alta.
- Event-Driven: comunicação por eventos assíncronos via broker (Kafka, RabbitMQ).
- Serverless: funções sob demanda em nuvem (AWS Lambda, Cloud Functions), sem gerenciamento de servidor.
- Layered (N-Tier): camadas horizontais (apresentação, negócio, dados) bem separadas.
- Hexagonal / Clean Architecture: núcleo de domínio isolado de detalhes de infraestrutura.
Boas práticas
- Documentar decisões em ADRs (Architecture Decision Records).
- Usar o C4 Model (Contexto, Contêiner, Componente, Código) para diagramar em níveis.
- Definir atributos de qualidade mensuráveis (ex.: p99 abaixo de 300 ms, uptime 99,9%).
- Evitar overengineering: escolher a arquitetura mais simples que resolve o problema real.
- Aplicar princípios como SOLID, DRY, KISS, YAGNI no código.
Quando cada padrão faz sentido
Segundo Martin Fowler (2015), ‘você não deve começar um novo projeto com microsserviços, mesmo que esteja convencido de que sua aplicação será grande o suficiente para justificá-los’. A recomendação é monólito primeiro, quebrando em serviços apenas quando a dor de manutenção justificar. Sistemas simples ou startups em validação normalmente prosperam com monólitos bem modularizados; produtos maduros com times independentes ganham com microsserviços.
Leia o artigo completo: Arquitetura de Software: padrões, princípios e como escolher a certa.
