Uma alternativa simplificada da Arquitetura Hexagonal
Imagine que você precisa criar, na empresa em que trabalha ou em um projeto pessoal, um novo Microservice usando Java e esse projeto tem que ter uma estrutura de código limpa e, principalmente, organizada de tal forma que possa ser incrementada aos poucos de acordo com novos Casos de Uso. Diante disso, você faz uma rápida busca na internet e encontra a tão famosa Arquitetura Hexagonal.
Porém, após uma leitura mais detalhada, você começa a perceber que para esse simples Microservice
não se faz necessário adicionar tantas camadas de abstração, mas também não sabe como tornar essa caixa de letrinhas mais
simples. É aqui que entra a minha proposta de arquitetura hexagonal simplificada. Lembrando que é somente uma sugestão
e que você pode torná-la mais simples ou mais complexa dependendo das suas necessidades!
Estrutura inicial dos pacotes da aplicação
Na imagem acima podemos ver a estrutura base da aplicação dentro do package com.hexagonal.simplified. A estrutura
base contém os pacotes adapter, application e domain. Por fim, por se tratar de um
projeto Spring Boot, podemos ver também a pasta resources com alguns arquivos de configuração. Vamos agora começar
a entrar nos detalhes de cada package.
Adapter
No package adapter adicionamos todo o código da nossa aplicação que se comunica com agentes externos como, por exemplo, banco de dados, requisições HTTP, eventos Kafka e cache.
Para organizar ainda mais o código eu sugiro dividir o que é comunicação de entrada na aplicação em um pacote chamado
in e comunicação de saída em um pacote chamado out. Dessa forma conseguimos identificar facilmente
o fluxo de I/O.
Application
A primeira coisa que quero dizer sobre o package application é que você pode chamá-lo como preferir. O importante aqui nesse pacote é que você adicione tudo que trata da camada de negócio da sua aplicação!
Na estrutura interna desse package eu adiciono outros dois sub-packages chamados port e usecase.
O pacote port contém as interfaces de comunicação de entrada e saída (I/O) e o pacote usecase contém, como o
próprio nome já diz, os Casos de Uso do projeto e o mesmo também pode ter um nome diferente.
Domain
Esse package é o mais "versátil" e pode conter muitos diferentes tipos de sub-packages. Nessa minha proposta de arquitetura simplificada eu diria que esse é o package que mais vai fugir à regra do hexagonal :) Porém, como de fato serão organizados os sub-packages vai depender de como você e sua equipe estruturam suas entidades, DTOs, enums e afins.
Outro ponto importante sobre o domain é que na arquitetura hexagonal esse package costuma se comunicar com os demais através de Mappers, Builders e similares. Aqui nesse meu projeto eu não dou importância a esse nível tão alto de isolamento entre os pacotes quando se trata dessas classes de domínio, sejam elas entidades de negócio ou não.
Aprofundando
No package adapter, como podem ver na imagem abaixo, eu implementei duas operações de entrada e duas de saída. As operações de entrada são um método HTTP GET e um consumidor Kafka e as de saída são um produtor Kafka e um repositório JPA responsável por operações de banco de dados.
No package application temos todas as interfaces de comunicações de entrada e saída dentro do sub-package port
sendo os UseCase as interfaces de entrada e os Port as interfaces de saída. Nesse mesmo package também fica
o sub-package usecase que é onde fica todo código de implementação das interfaces de entrada (regras de negócio).
Por último, o package domain que é o local que, como falei anteriormente, contém todas classes de entidade, enums, mappers, DTOs e similares. Caso use projections em seu projeto você também pode criar aqui um sub-package para adicionar as respectivas interfaces dessas projections.
Fim!
Esse é o resumo da ópera! Caso surjam dúvidas deixe o seu comentário que irei responder o mais breve possível. O código fonte do projeto está disponível neste link: Simplified Hexagonal. Abraços!