Arquitetura Hexagonal

Bom, toda vez que estudo algo novo nesse mundo de tecnologia eu falo para mim mesmo que vou documentar para compartilhar sobre e até mesmo para eu lembrar e um futuro próximo rs. São tantas coisas que estudamos que as vezes não temos o assunto na ponta da língua. Espero que dessa vez vai!

A arquitetura hexagonal foi apresentado por Alistair Cockburn em 2005 como uma alternativa ao modelo em camadas. Cockburn é um dos principais expositores do “caso de uso” para documentar processos e requisitos comportamentais de um software.

Quando discutimos sobre arquitetura de um software, temos alguns temas como forma de ponto de partida.

1. O Software não deve ser definido por um framework.

O que quero dizer com isso é que, sim o seu software é construído COM um framework e não construído POR um framework, ou seja, se você precisar sempre herdar uma classe ou definir um padrão de nomenclatura de um framework para suas classes, atributos, métodos , isso é um ponto negativo pois você sempre estará se adequando a um framework.

2. Arquitetura em camadas

Essa abordagem é muito usada por projetos que já estão em produção, é uma forma de organizar, estruturar o software. Não estou dizendo que é um padrão errado e não deve ser usado, aliás, nesse mundo de desenvolvimento de software, não temos certo ou errado, apenas conceitos e ferramentas que ajudam e facilitam o nosso cotidiano.

Bom, com isso podemos ver que o conceito de arquitetura hexagonal visa ser uma opção para substituir o padrão de hierarquia que temos quando desenvolvemos o software pensando em camadas (de cima para baixo ou da esquerda para direita), como podemos ver abaixo:

De uma forma geral, essa forma simétrica tende levar o desenvolvedor a uma visão simplista de como implementar o software, impossibilitando de uma forma geral desenvolver uma aplicação mais complexa, robusta.

Normalmente desenvolvemos soluções de softwares quase sempre focadas no topo de um framework e banco de dados, ou seja, o software ainda é modelado como um reflexo do banco de dados ao invés de realizarmos o design de software voltado ao domínio de negócio.

Hexagonal Architecture (Ports and Adapters) é uma estratégia para desacoplar e criar casos de uso que abstraem os detalhes externos, com objetivo de criar sistemas desacoplados, tanto com a interface do usuário quanto do banco de dados.

O Application Core, representado por um hexágono é onde contêm todas as regras de negócio que a aplicação precisa conhecer e executar. Aqui temos o conceito de UseCases, nada mais é que uma abstração do que você gostaria de fazer no seu core da aplicação, todas a camadas lógicas, validações devem acontecer aqui.

As Ports é uma forma que o application core consiga se comunicar com o mundo à fora, permitindo a entrada ou saída de dados, ou seja, são interfaces as quais o core irá se comunicar. Aqui temos o conceito de input port, onde o application core irá expor para o mundo à fora sua funcionalidade, exemplo: IManipuleteOperationUseCase. Temos também o conceito de output port, uma interface a qual o core usa para buscar informações fora de si, exemplo: IOperationRepository.

Os Adapters são componentes de softwares que permitem uma tecnologia em particular interagir com uma porta, ou seja, as interações acontecem via adaptadores.

Temos dois tipos de adapters, quando os adapters invocam o application core chamamos de inbound adapters, exemplo OperationController de uma WebAPI, já quando acontece ao contrário eles são chamados de outbounds adapters.

Mas como podemos começar? Bom, acredito que o primeiro passo é ter um projeto para especificar a application core (Domain), exemplo, caso queremos desenvolver uma API, temos 2 projetos, um WebAPI que referência o projeto Application e a conversa entre os dois acontece pelo um serviço de aplicação e um projeto para Infrastructure.

Há diversas maneiras para fazer isso, você pode tentar criar a sua.

Pontos positivos

Tecnologias fáceis de trocar;
Fácil criação e remoção de adapters;
Facilidade de testar a aplicação.

Pontos negativos

Não há uma orientação sobre como organizar o código;
Complexidade inicial (entendimento, criação).

Quando utilizar?

Muito se fala em aplicar a arquitetura hexagonal em apenas sistemas grandes, devido um grau de esforço de desenvolvimento e entendimento no primeiro momento, visto que em sistemas pequenos dificilmente gerará manutenções, desenvolvimento de novas features e talvez não seja interessante o custo, esforço.

Porém, isso não está escrito em pedra, uma vez que todo desenvolvimento de software demanda uma análise e discussões técnicas, podendo ter n variáveis, desde conhecimento do time quanto necessidade do negócio.

Publicado originalmente no Medium.