Arquitetura Hexagonal e Arquitetura de Domínio Orientada a Eventos em Java e Spring
Atualmente, estou explorando a implementação conjunta da Arquitetura Hexagonal e da Arquitetura de Domínio Orientada a Eventos utilizando Java e Spring. Embora as tecnologias possam variar, a base teórica dessas arquiteturas deve permanecer a mesma. No entanto, estou enfrentando dificuldades para fazê-las funcionar bem em conjunto. Com base no estudo que realizei até agora, a arquitetura deve seguir uma estrutura de duas zonas (dentro e fora do hexágono) e três camadas principais: Domínio, Aplicação e Infraestrutura.
Camadas da Arquitetura Hexagonal
-
Domínio
Esta é a camada central do hexágono, onde residem as Entidades, que devem ser autocontidas, representando o coração da lógica de negócio. Além das entidades, também encontramos aqui Repositórios, ValueObjects, Fábricas e Eventos. Toda a lógica de negócio deve estar encapsulada nesta camada, de forma a garantir que o domínio permaneça imune a mudanças externas. A arquitetura promove a independência do domínio em relação a detalhes técnicos. -
Aplicação
Na borda do hexágono está a camada de aplicação. É onde se encontram as portas de entrada, ou seja, os pontos de comunicação que expõem as funcionalidades do sistema. Nesta camada, tipicamente, encontramos adaptadores REST, que agem como intermediários entre o mundo externo (entrada) e a lógica do domínio. É aqui que os casos de uso são implementados, coordenando as interações entre o usuário e a lógica de negócio, sem interferir na lógica do domínio em si. -
Infraestrutura
A camada mais externa, fora do hexágono, é dedicada à infraestrutura. Esta camada lida com os adaptadores de saída, ou seja, componentes responsáveis por interagir com serviços externos, como bancos de dados, sistemas de mensagens e APIs de terceiros. Além disso, é nesta camada que frameworks e bibliotecas externas são utilizados. A implementação de Repositórios e outras dependências externas, como envio de eventos ou chamadas a serviços externos, acontece aqui.
Integração de Arquitetura Hexagonal com Arquitetura Orientada a Eventos
A Arquitetura de Domínio Orientada a Eventos complementa a arquitetura hexagonal ao tratar a comunicação entre as diferentes camadas e sistemas de forma reativa, utilizando eventos como mecanismo principal. Isso permite que alterações no domínio disparem eventos que outros componentes possam reagir. A vantagem dessa abordagem é a desacoplamento, já que um componente não precisa conhecer diretamente o outro, apenas o evento que foi disparado.
Desafios e Perguntas Comuns
1. Por que os adaptadores são tipicamente implementados na camada de Aplicação ou Infraestrutura?
Os adaptadores de entrada (como controladores REST) são colocados na camada de Aplicação, pois eles são responsáveis por expor as funcionalidades do sistema e lidar com a comunicação externa. Os adaptadores de saída (como repositórios e serviços externos) ficam na camada de Infraestrutura, já que lidam com detalhes técnicos e dependências externas, mantendo o domínio independente de tecnologias específicas.
2. Qual a função de Repositórios e Serviços de Domínio?
Os Repositórios e Serviços de Domínio são interfaces definidas no Domínio para representar operações sobre as entidades, como a persistência de dados. Eles encapsulam a lógica de como as entidades são acessadas e modificadas, mas sua implementação concreta ocorre na camada de Infraestrutura, usando tecnologias como bancos de dados ou APIs externas. Isso mantém o domínio isolado de detalhes técnicos.
3. Toda a lógica deveria ir para a Entidade?
Embora as Entidades devam conter a lógica de negócio central, é comum que regras mais complexas, envolvendo múltiplas entidades, sejam implementadas em Serviços de Domínio. Isso mantém as entidades simples e focadas em suas responsabilidades principais, enquanto os serviços coordenam interações mais complexas entre diferentes partes do domínio.
Event-Driven Architecture (Arquitetura Orientada a Eventos)
Na Arquitetura Orientada a Eventos, as alterações de estado no sistema são comunicadas por meio de eventos. Um evento representa algo que aconteceu, como uma transação sendo completada ou um pedido sendo feito. A arquitetura hexagonal pode se beneficiar dessa abordagem, já que eventos podem ser disparados a partir de alterações nas entidades do domínio, e esses eventos podem ser consumidos por outros componentes da aplicação ou mesmo por sistemas externos.
Exemplo de Integração:
Suponha que uma entidade Pedido dispare um evento de PedidoCriado. Esse evento pode ser capturado por um componente de infraestrutura que persiste o pedido em um banco de dados, ou pode ser transmitido para outro sistema externo, como um serviço de notificação.
Event Sourcing
Um conceito relacionado à arquitetura orientada a eventos é o Event Sourcing, onde o estado de uma entidade é reconstruído a partir de uma sequência de eventos que ocorreram no passado. Isso pode trazer uma série de vantagens em termos de auditabilidade e flexibilidade, mas também aumenta a complexidade da implementação.
Estrutura de Pastas
A organização de pastas em uma aplicação que implementa essas duas arquiteturas em conjunto pode variar, mas uma estrutura comum pode se parecer com o seguinte:
/src /main /java /com/empresa /dominio /entidades /servicos /repositorios /eventos /aplicacao /controladores /casosDeUso /infraestrutura /repositorios /adaptadoresExternos /mensageria
Essa estrutura segue o princípio de separação de responsabilidades, com cada camada claramente definida e separada de acordo com as funções descritas anteriormente.
Conclusão
Implementar a Arquitetura Hexagonal com uma abordagem Event-Driven em Java e Spring pode ser desafiador, mas extremamente recompensador. O domínio permanece isolado de dependências tecnológicas externas, o que facilita a manutenção e evolução do sistema ao longo do tempo. Já a orientação a eventos aumenta a flexibilidade e a reatividade da aplicação, permitindo que as diferentes partes do sistema colaborem de maneira mais solta e eficiente.
