Arquitetura de software é a espinha dorsal de qualquer sistema: define os componentes, suas propriedades externas e seus relacionamentos (Wikipedia, 2026-07-04). Escolher a errada pode gerar retrabalho, lentidão e dívida técnica. Este guia mostra os 8 tipos mais comuns e quando cada um brilha.
1. Monolítica
Um único bloco de código que roda como um processo. Ideal para MVPs, projetos pequenos ou times enxutos. O deploy é simples, mas a escalabilidade exige replicar o sistema inteiro. Exemplo: um site institucional com poucas funcionalidades.
2. Microsserviços
Cada serviço é independente, com seu próprio banco e ciclo de vida. Perfeita para sistemas grandes, com times separados por domínio. Exige maturidade em DevOps. Exemplo: plataformas de e-commerce que escalam catálogo e pagamento separadamente.
3. Em Camadas
Separa o sistema em apresentação, negócio e dados. É a mais difundida em sistemas corporativos. Fácil de entender, mas o acoplamento entre camadas pode virar um problema. Exemplo: sistemas ERP tradicionais.
4. Hexagonal (Ports & Adapters)
Isola o núcleo do negócio de detalhes de infraestrutura (banco, API, fila). Cada adaptador se conecta por portas. Excelente para testabilidade e manutenção. Exemplo: aplicações financeiras que precisam trocar de banco sem afetar regras.
5. Orientada a Eventos
Componentes se comunicam por eventos assíncronos (mensageria). Ideal para sistemas em tempo real, notificações e fluxos reativos. Exige cuidado com consistência eventual. Exemplo: sistemas de rastreamento de entregas.
6. Baseada em Componentes
Divide o sistema em componentes reutilizáveis com interfaces bem definidas. Útil em projetos com muitos módulos que podem ser recombinados. Exemplo: suítes de escritório (editor de texto + planilha).
7. Pipes and Filters
Processa dados em sequência: cada filtro transforma a entrada e passa adiante. Perfeita para ETL, processamento de streams e pipelines de dados. Exemplo: sistemas de log que filtram, agregam e armazenam.
8. Espaço de Tuplas (Linda)
Usa um espaço compartilhado onde processos escrevem e leem tuplas de forma assíncrona. Adequada para sistemas distribuídos com descoberta dinâmica. Exemplo: redes de sensores que coordenam tarefas sem um servidor central.
Qual escolher? Comece com a mais simples que atende o problema. Se o projeto é pequeno e o time único, monolítica. Se há domínios distintos e escalabilidade independente, microsserviços. Se o foco é testabilidade e manutenção, hexagonal. Nenhuma arquitetura é bala de prata, o contexto do projeto manda.
FAQ
Qual a diferença entre arquitetura monolítica e microsserviços?
Na monolítica, todo o código roda em um único processo; em microsserviços, cada serviço é independente, com deploy e banco próprios. Monolítica é mais simples de começar; microsserviços escalam partes isoladas.
Quando usar arquitetura em camadas?
Use em sistemas corporativos tradicionais, onde a separação entre apresentação, negócio e dados é clara e o time é familiarizado com o padrão. Evite se o sistema exigir alta testabilidade ou mudanças frequentes de infraestrutura.
O que é arquitetura hexagonal?
É um padrão que isola o núcleo do negócio de detalhes externos (banco, API, UI) usando portas e adaptadores. Facilita testes automatizados e troca de tecnologias sem afetar as regras de negócio.
Qual arquitetura é melhor para sistemas em tempo real?
A orientada a eventos, com mensageria assíncrona (Kafka, RabbitMQ). Permite processar notificações, streams e atualizações em tempo real sem bloquear outros componentes.
Posso misturar arquiteturas no mesmo sistema?
Sim. É comum ter um núcleo monolítico com módulos orientados a eventos, ou microsserviços que usam arquitetura hexagonal internamente. A escolha deve ser pragmática, não purista.
Como escolher a arquitetura ideal para um projeto novo?
Analise o tamanho do time, a complexidade esperada, a necessidade de escalabilidade independente e a maturidade em DevOps. Comece simples (monolítica ou em camadas) e evolua para padrões mais complexos conforme a demanda crescer.