Universidade Federal de Pernambuco | Centro de Informática | Sistemas de Informação

Desacoplamento das camadas do código utilizando

Arquitetura Hexagonal, um exemplo prático em Rust

Orientação: Prof Dr Vinicius Cardoso Garcia

Avaliação: Prof Dr Kiev Santos da Gama
Autoria: Maria Estela da Costa e Lima Souza
Tópicos

● Introdução
● Metodologia
● Conceitos
● Projeto
● Resultados
● Conclusões
Contexto
● Década de 60 Engenharia de Software
○ Surgimento do computador comercial,
video game, video cassete

● Década de 90 Arquitetura de software

○ Novas linguagens de programação
Arquitetura de Software

Bass considera que é a estrutura (ou estruturas) do sistema, a qual é

composta de elementos de software, das propriedades externamente visíveis
desses elementos, e dos relacionamentos entre eles; é a abstração do sistema -
( Bass,2003).
Arquitetura de Software

"A arquitetura é a abstração do sistema utilizando ferramentas de

visualização de como aquele sistema irá se comportar. Quais decisões foram
tomadas para construção do design do sistema, além de que, a arquitetura é
peça fundamental em sua evolução, ditando assim o que pode e o que não

pode ser feito durante todo o ciclo de vida do software" (Evans, 2015).
Objetivos
O objetivo geral do trabalho foi implementar o padrão de Arquitetura Hexagonal a fim de
entender como ele favorece no desacoplamento do código e como essa arquitetura pode ajudar no
desenvolvimento de software.

Objetivos específicos
● Entender a Arquitetura Hexagonal;
● Mapear os pontos fortes e fracos da implementação da Arquitetura Hexagonal;
● Verificar a qualidade do código.
Tópicos

● Introdução
● Metodologia
● Conceitos
● Projeto
● Resultados
● Conclusões
Metodologia

A metodologia proposta para essa monografia foi uma prova de

conceito e o objeto de estudo foi uma implementação para entender a
arquitetura hexagonal.
Limitações à validade dos resultados

● Não foram feitas avaliações quantitativas para a análise da

aplicação, tendo risco de uma resultados tendenciosa;
● A análise da qualidade de código foi feita através do Rust-
Analyze ;
Etapas do Projeto

Definição do Requisitos para o

Objetivo projeto Validação do projeto

1 3 5

2 4 6

Leitura sobre o tema Desenvolvimento do Resultados

projeto
Tópicos

● Introdução
● Metodologia
● Conceitos
● Projeto
● Resultados
● Conclusões
Arquitetura Hexagonal

A arquitetura hexagonal foi criada e documentada em 2005 por

Alistair Cockburn, segundo Cockburn: "É uma arquitetura também
chamada de Ports and Adapters, é uma forma de organizar o código em
camadas, ela é um design de software, e busca separar cada qual parte
de código com sua responsabilidade, fazendo tal processo isolando
totalmente a lógica da aplicação do mundo externo" (Cockburn, 2005).
Arquitetura Hexagonal

Segundo Cockburn um dos grandes problemas atualmente

dos grandes projetos de software é a infiltração de lógica de
negócio na interface com o usuário ou banco de dados
(Cockburn, 2005).
Arquitetura Hexagonal
Arquitetura Hexagonal
Adaptadores

● Os adaptadores podem ser facilmente substituídos, por não possuir contato

direito nenhum com outras camadas de código, facilitando a mudança de
infraestrutura sem causar um impacto significativo ao projeto (EVANS, 2015).
● Recebem chamadas de fora do sistema e são responsáveis por enviar essas
chamadas para os métodos referentes a cada chamada (EVANS, 2015).
Arquitetura Hexagonal
Portas

● Representada como uma interface que traz o isolamento do domain, nela que
será feito o tratamento dos dados que entram no domain.(GRIFFIN, 2021).
● Um sistema pode possuir várias portas de entrada e de saída sempre localizadas
no hexágono interior, junto às classes de domínio (GRIFFIN, 2021).
Arquitetura Hexagonal
Domain

● O domain não tem contato direto com outras partes do negócio

(GRIFFIN, 2021)
● Responsável por se referir a toda lógica de negócio, seja como essas
regras estejam implementadas. (GRIFFIN, 2021)

Inversão de Controle
Tópicos

● Introdução
● Metodologia
● Conceitos
● Projeto
● Resultados
● Conclusões
Levantamento de Requisitos

● Definição da estrutura de pastas

● Duas conexões externas uma do lado cliente (HTTP) outra do lado do servidor
(Banco de Dados)
● Para isso foi construído um sistema de biblioteca com função de leitura, edição,
criação e remoção de livros
Estrutura de Pastas
Camada Critério
Adapter Dentro do adapter existirão dois módulos.
1. Para as requisições HTTP (de
entrada)
2. Para as chamadas do Banco de
Dados (de saída)

Ports Nas portas estarão as entradas dos payloads

e o seguinte critério foi estabelecido para
entrar no Domain:
1. Para a entrada HTTP no haverá um
campo "name" que no Domain
corresponde a "book_name". Antes
ir para o Domain é responsabilidade
da porta modificar esse campo para o
que é esperado no Domain
2. Depois da validação do domain, será
enviado o novo payload para porta
de saída para o banco de dados
Domain Terá uma regra de negócio, de caso o campo
"book_name" seja igual a "livro teste", será
adicionado o valor true no campo "is_test"(o
default é false)
Payloads

Port (inbound) Domain/ Port (outbound)

Implementação
Adaptadores
Portas
Implementação
Domain
Tópicos

● Introdução
● Metodologia
● Conceitos
● Projeto
● Resultados
● Conclusões
Resultados
Análise qualitativa :
● Garantia de qualidade de código
● Desacoplamento de código

Cores correspondentes aos resultados

Nota Cor
Atendeu as expectativas

Abaixo das expectativas

Não atendeu as
expectativas
Rust Analyze - Garantia de código

Funcionalidade Status
Remover code que não é Ativado
necessário
Remove vírgulas e importações Ativado
triviais
Juntar linhas consecutivas entre ifs Ativado
Destacar breakpoints Ativado
Importar configurações para todos Desativado
os arquivos
Restartar o serviço Desativado
automaticamente por causa de
alguma configuração
 Resultados - Garantia de código

Na primeira vez que a ferramenta foi rodada houve sugestão de melhorias,

foram feitos os ajustes e houve uma resultado de melhoria no tempo de
compilamento do projeto, diminuindo significativamente, de 0.61s para 0.22s.
 Resultado - Desacoplamento de código

MÉTRICAS MVC MVP ARQUITETURA ARQUITETURA

ORIENTADA A HEXAGONAL
EVENTOS

Baixo acoplamento do
design de código
(estrutura de pastas)
Cores correspondentes
Pouca dependência de aos resultados
módulos da aplicação
Nota Cor
Funções com
Atendeu as
responsabilidade única expectativas

Reutilização de código Abaixo das

expectativas

Não atendeu as
expectativas
Resultado - Desacoplamento de código

CRITÉRIO IMPLEMENTAÇÃO
As interfaces implementadas são
utilizadas no código;
A camada de domain tem apenas
regras de negócio e é agnóstico a Cores correspondentes aos resultados
outras partes do código;
A porta faz chamada apontando Nota Cor
pro domain e os adapters apontam
Atendeu as expectativas
pras portas;
Abaixo das expectativas

Não atendeu as
expectativas
Resultado - Análise da Arquitetura Hexagonal
- Jesse Griffin
CRITÉRIO IMPLEMENTAÇÃO

Adição de features rápido.

Alterações no código que não afetam outro

código.

Mais fácil de adicionar recursos, exigindo Cores correspondentes aos resultados

menos código para torná-los função.
Nota Cor
Código pouco repetido.
Atendeu as expectativas

Manutenabilidade Abaixo das expectativas

Não atendeu as
expectativas
Tópicos

● Introdução
● Metodologia
● Conceitos
● Projeto
● Resultados
● Conclusões
Conclusão
Esse trabalho se propôs a implementar a
Arquitetura Hexagonal e a partir disso entender o
sucesso e melhoria na implementação do desacoplamento
de código. Para além disso, verificar a qualidade de
código e comparar o design arquitetural com outras
arquiteturas.
 Pontos fracos e fortes

● A arquitetura hexagonal a outras arquiteturas: se destaca nos quesitos de pouca

dependência de módulos, responsabilidade única e estrutura de pastas,
porém no quesito reutilização do código as arquiteturas MVC e MVP foram
melhores
● A avaliação de desacoplamento - foi possível notar sucesso nos aspectos citados
 Pontos fracos e fortes

● Análise da arquitetura de acordo com Domain-Driven Laravel -

na análise em questão foi perceptível pela autora o sucesso nos
pontos de adição de features rápido, alteração em uma parte de
código não afeta a outra, fácil de adicionar e manusear
recursos. Os pontos de melhoria na arquitetura foram mapeados,
código pouco repetido e manutenabilidade.
Desafios do trabalho
Entender cada camada da Arquitetura para
implementar olhando para o ponto de desacoplamento de
código. Aprender uma nova linguagem de programação.
Entender especificidades do Rust para implementação
dessa Arquitetura. Aplicar critérios de sucesso e melhoria
nos resultados.
Trabalhos futuros
● Fazer pesquisas para validação da implementação da arquitetura Hexagonal;
● Entender como a arquitetura hexagonal se comporta tendo em vista escalabilidade e
se é de fácil implementação de testes ;
● Durante o trabalho e estudo da Arquitetura foi notável que ainda não existiam tantos
estudos acadêmicos para esse estilo, então seria importante fazer revisões literárias
entendendo as lacunas que ainda existem nessa área ;
Referências

Len Bass, Paul Clements, and Rick Kazman. Software Architecture in Practice. Addison-Wesley
Longman Publishing Co., Inc., Boston, MA, USA, 1998., 2nd edition, April 2003.
Perry, Dewayne E. and Alexander L. Wolf. “Foundations for the study of software architecture.”
ACM SIGSOFT Softw. Eng. Notes 17 (1992): 40-52.
Evans, E.Domain Driven Design Referencia 2015, disponível em <
https://www.ricardopedias.com.br/assets/docs/ddd-referencia.pdf>. Acesso em : 09 out. 2022.
Griffin, J. . Hexagonal-Driven Development. In: Domain-Driven Laravel 2021, Apress, Berkeley, CA.
disponível em < https://doi.org/10.1007/978-1-4842-6023-4_17>. Acesso em: 08 set. 2022.
Cockburn, A. Hexagonal Architecture. 2014. Disponível em: <http://wiki.c2.com/?
HexagonalArchitecture>. Acesso em: 10 ago. 2022.
Muito obrigado!
Dúvidas?