Arquitetura Hexagonal: Separando regras de negócio das dependências externas
A Arquitetura Hexagonal é um estilo arquitetural que busca isolar as regras de negócio das tecnologias utilizadas pela aplicação. Essa abordagem facilita testes, manutenção e evolução do sistema, permitindo trocar bancos de dados, APIs ou frameworks sem impactar o domínio da aplicação.
O problema das aplicações tradicionais
Em muitos projetos, a lógica de negócio acaba ficando fortemente acoplada às tecnologias utilizadas.
Por exemplo, um serviço pode depender diretamente do Entity Framework, de uma API externa ou de uma fila de mensagens. Isso dificulta testes e torna alterações mais custosas.
A Arquitetura Hexagonal propõe justamente separar essas responsabilidades.
O que é a Arquitetura Hexagonal?
Também conhecida como Ports and Adapters, ela organiza a aplicação em torno do domínio.
No centro está a regra de negócio. Ao redor, ficam as portas (interfaces) e os adaptadores responsáveis por comunicar a aplicação com o mundo externo.
A ideia principal é:
O domínio não deve conhecer banco de dados, APIs ou frameworks.
Portas e Adaptadores
Portas
As portas representam contratos que definem como o domínio se comunica com o exterior.
Exemplo:
public interface IOrderRepository
{
Task Save(Order order);
}
Adaptadores
Os adaptadores implementam essas interfaces utilizando alguma tecnologia específica.
public class OrderRepository : IOrderRepository
{
public async Task Save(Order order)
{
// Persistência utilizando Entity Framework
}
}
Dessa forma, caso seja necessário trocar o banco de dados ou a tecnologia de persistência, o domínio permanece inalterado.
Exemplo prático
Imagine um sistema de e-commerce.
Ao criar um pedido, a regra de negócio precisa:
- Salvar o pedido;
- Processar o pagamento;
- Enviar uma notificação ao cliente.
As portas poderiam ser:
public interface IPaymentService
{
Task ProcessPayment(decimal amount);
}
public interface INotificationService
{
Task Send(string message);
}
Enquanto os adaptadores poderiam utilizar:
- Stripe para pagamentos;
- RabbitMQ para mensageria;
- SendGrid para envio de e-mails.
A lógica de negócio continuaria a mesma, independentemente da tecnologia utilizada.
Estrutura de pastas
Uma possível organização seria:
Domain
├── Entities
├── Services
├── Interfaces
Application
├── UseCases
Infrastructure
├── Repositories
├── ExternalServices
Api
├── Controllers
Vantagens
Maior modularidade
As responsabilidades ficam bem definidas, facilitando manutenção e evolução.
Facilidade para testes
É possível criar mocks das interfaces e testar as regras de negócio sem depender de banco de dados ou serviços externos.
Independência de tecnologia
Frameworks e bibliotecas podem ser substituídos sem alterar o núcleo da aplicação.
Melhor manutenibilidade
Mudanças em integrações externas têm impacto reduzido no sistema.
Desvantagens
Complexidade inicial
Para projetos pequenos, a quantidade de interfaces e abstrações pode parecer excessiva.
Mais código
A criação de portas e adaptadores aumenta a quantidade de arquivos e classes.
Curva de aprendizado
Equipes que nunca trabalharam com essa abordagem podem precisar de um tempo para se adaptar.
Quando utilizar?
A Arquitetura Hexagonal faz mais sentido em sistemas que:
- Possuem regras de negócio complexas;
- Precisam de alta testabilidade;
- Possuem diversas integrações externas;
- Tendem a evoluir ao longo do tempo.
Em aplicações simples ou pequenos CRUDs, o custo da complexidade adicional pode não compensar.
Conclusão
A Arquitetura Hexagonal promove uma separação clara entre domínio e infraestrutura, tornando o sistema mais flexível, testável e preparado para mudanças futuras.
Embora exija mais abstrações e uma curva inicial de aprendizado, seus benefícios costumam aparecer em projetos de médio e grande porte, especialmente quando a manutenção e a evolução contínua são fatores importantes.
Saiba mais
- Martin Fowler — Hexagonal Architecture
- Alistair Cockburn — Ports and Adapters Pattern
- Microsoft - Architectural Styles
- Clean Architecture - Robert C. Martin