Arquitetura de Software
Arquitetura hexagonal explicada
Entenda como arquitetura hexagonal separa regras de negócio de frameworks, bancos e integrações externas.
A arquitetura hexagonal protege o domínio da aplicação ao colocar frameworks, banco de dados e integrações nas bordas.
O domínio fica no centro
A ideia central é simples: regras de negócio não deveriam depender diretamente de HTTP, ORM, filas ou serviços externos. Quando o domínio conhece detalhes demais, cada troca de infraestrutura vira uma mudança arriscada.
Em uma aplicação de orçamento, por exemplo, calcular impostos, validar regras comerciais e aprovar limites deve ser testável sem subir servidor, banco ou mensageria.
- Coloque entidades e regras no núcleo.
- Evite importar bibliotecas de infraestrutura no domínio.
- Teste regras com objetos simples e dados controlados.
Portas definem contratos
Portas expressam o que a aplicação precisa: salvar pedido, enviar notificação, buscar cliente, publicar evento. Adaptadores implementam esses contratos usando banco, API, fila ou qualquer tecnologia concreta.
Essa separação dá liberdade para trocar implementação sem reescrever casos de uso. Também melhora testes, porque dependências externas podem ser substituídas por doubles em cenários específicos.
- Nomeie portas pelo comportamento, não pela tecnologia.
- Mantenha adaptadores pequenos e explícitos.
- Use contratos para proteger integrações críticas.
Aplique onde há ganho real
Arquitetura hexagonal não precisa transformar todo projeto em uma pilha de camadas. Em CRUDs simples, exagerar abstrações pode atrapalhar. O padrão brilha quando regras são importantes e a aplicação precisa durar.
Uma boa régua é perguntar: este fluxo muda com frequência, tem integrações relevantes ou carrega regra de negócio sensível? Se sim, vale proteger melhor os limites.
- Use a abordagem completa em fluxos críticos.
- Prefira simplicidade em telas administrativas triviais.
- Revise a arquitetura quando o domínio crescer.