UNIVERSIDADE FEDERAL DE PERNAMBUCO

CENTRO DE INFORMÁTICA
SISTEMAS DE INFORMAÇÃO

MARIA ESTELA DA COSTA E LIMA SOUZA

DESACOPLAMENTO DAS CAMADAS DE CÓDIGO UTILIZANDO

ARQUITETURA HEXAGONAL: UM EXEMPLO PRÁTICO EM RUST

Recife
2022
 MARIA ESTELA DA COSTA E LIMA SOUZA

DESACOPLAMENTO DAS CAMADAS DO CÓDIGO UTILIZANDO

ARQUITETURA HEXAGONAL, UM EXEMPLO PRÁTICO EM RUST

Trabalho apresentado ao Programa de Graduação em

Sistemas de Informação do Centro de Informática da
Universidade Federal de Pernambuco como requisito
parcial para obtenção do grau de Bacharel em Sistemas
de Informação.

Orientador: Vinicius Cardoso Garcia

Recife
2022
 MARIA ESTELA DA COSTA E LIMA SOUZA

DESACOPLAMENTO DAS CAMADAS DO CÓDIGO UTILIZANDO

ARQUITETURA HEXAGONAL, UM EXEMPLO PRÁTICO EM RUST

Trabalho apresentado ao Programa de Graduação em

Sistemas de Informação do Centro de Informática da
Universidade Federal de Pernambuco como requisito
parcial para obtenção do grau de Bacharel em Sistemas
de Informação.

Recife, 20 de Outubro de 2022.

BANCA EXAMINADORA

__________________________________
Prof. Vinicius Cardoso Garcia (Orientador)
UNIVERSIDADE FEDERAL DE PERNAMBUCO

__________________________________
Prof. Kiev Santos da Gama (2º membro da banca)
UNIVERSIDADE FEDERAL DE PERNAMBUCO
Dedico este trabalho de conclusão de curso primeiramente
a minha família, que sempre me apoiou em todas as
decisões da minha vida, meus pais que buscaram me dar
uma educação de qualidade e sempre mostraram o valor da
educação como transformadora do mundo e para além
disso, por me ensinarem e mostrarem como em pequenos
atos de esforço e amor podemos fazer a diferença na vida
dos outros, obrigada João, Ana e Mateus, vocês fazem
muita diferença na minha vida. Dedico também a todos os
meus amigos da faculdade, que durante esses anos sempre
estiveram comigo, me deram apoio nos momentos que
precisei e fizeram com que essa jornada da minha vida
fosse leve, cheia de alegria e os momentos de dificuldade
foram menores porque vocês estavam lá, então obrigada a
Luana Ribeiro, Pedro Henrique, Pedro Augusto, Daniel
Carvalho, Eva Marla e Igor Fernandes por essa jornada e
por fim, agradecer a todos os meus professores do Centro
de Informática por fazerem com que minha jornada no
centro fosse tão importante para a vida que levo
atualmente, em especial dedico a Vinicius Cardoso Garcia
e Fernando Marciano Neto que me ensinaram para além da
programação a ver a tecnologia como algo que pode ajudar
outras pessoas, por estarem em muitos momentos
importantes na minha jornada no Cin e por terem me
ajudado diversas vezes.
 AGRADECIMENTOS

Em primeiro lugar, agradeço a Deus por ter me abençoado com pessoas incríveis ao
longo de minha jornada pessoal e profissional. Agradeço a meus amigos e as pessoas do meu
trabalho pela paciência que tiveram em escutar meus desabafos sobre a realização deste
trabalho, a iFood pelo suporte e compreensão nos momentos que precisei me dedicar mais a
esse trabalho de conclusão.
Ademais sou grato por todos amigos que fiz na faculdade, que sempre estiveram
dispostos a me ajudar em momentos difíceis do curso. Agradeço a meus professores e
principalmente ao meu orientador, Vinicius Garcia, pela ajuda e conselhos dados não só na
realização desse trabalho, mas durante minha graduação.
Ao Centro de Informática da Universidade Federal de Pernambuco - CIN-UFPE, pela
excelente estrutura física e pessoal proporcionada a todos os seus alunos. E por último,
agradeço a minha família, Ana, João e Mateus, por todo suporte e amor. Por causa deles,
sempre acreditei que seria capaz de atingir meus objetivos.
Epígrafe

"O mais importante é a mudança,

o movimento, o dinamismo, a energia."
(Clarice Lispector)
 RESUMO

Nos últimos anos houve uma crescente evolução no desenvolvimento de software e

cada vez mais buscam-se métodos para o desenvolvimento de sistemas complexos e de larga
escala, com ganhos em agilidade e eficiência na manutenção e construção destes. Pensar na
arquitetura do software é desenvolver o esqueleto de um sistema, e esse é um dos meios para
que haja agilidade no desenvolvimento desses programas.
Atualmente existem diversos modelos de arquitetura, dentre eles, a arquitetura
hexagonal, que traz um desacoplamento nas camadas do código. O objetivo deste trabalho é
investigar os princípios que levam a escolha por uma arquitetura hexagonal e demonstrar de
forma prática a implementação de um software baseado em uma arquitetura hexagonal para
entender as vantagens dessa arquitetura para o desenvolvimento e manutenção de sistemas.

Palavras-chave: Desenvolvimento Ágil, Arquitetura de Software, Arquitetura Hexagonal,

Desacoplamento de Código.
 ABSTRACT

On the last few years there was a crescent evolution in software development and even
more we look for methods of developing complex methods on a large scale, with agility and
efficiency gains on maintenance and building of those. To think about software architecture is
to develop a system skeleton, and this is one of the ways so that there is agility on developing
these programs.
Nowadays there are multiples models of architecture, such as architecture hexagonal
which brings a decoupling at the codes's layers. The goal of these job is to investigate the
principles that leads to the choice for an architecture hexagonal and show as an easy practice
the implementation of a software based on an architecture hexagonal to understand the
advantages of this architecture to system development and maintenance.

Keywords: Agile Development, Software Architecture, Hexagonal Architecture .

 LISTA DE ILUSTRAÇÕES

Figura 1 — Model View Controller 20

Figura 2 — Model View Present 21
Figura 3 — Event Drive Architecture 22
Figura 4 — Adaptadores Arquitetura Hexagonal 26
Figura 5 — Camadas da Arquitetura Hexagonal 27
Figura 6 — Princípios e Exemplos 29
Figura 7 — Cronograma Planejado (parte 1) 30
Figura 8 — Cronograma Planejado (parte 2) 30
Figura 9 — Goal Question Metric 31
Figura 10 — Fluxo da Arquitetura Hexagonal 37
Figura 11 — [Port inbound] Payload de Entrada HTTP - POST 39
Figura 12 — [Domain] Payload de Entrada no Domain 40
Figura 13 — [Port Outbound] Payload para salvar no Banco de Dados 40
Figura 14 — Estrutura de Pastas - main 41
Figura 15 — Estrutura de Pastas - arquivos 42
Figura 16 — Exemplo de Adapter na Arquitetura Hexagonal 43
Figura 17 — Exemplo de Adapter na Arquitetura Hexagonal 44
Figura 18 — Exemplo de Portas na Arquitetura Hexagonal 45
Figura 19 — Exemplo de Domain na Arquitetura Hexagonal 46
Figura 20 — GQM - Definição de métricas 48
Figura 21 — Resultado Rust-Analyze (parte 1) 50
Figura 22 — Resultado Rust-Analyze (parte 2) 51
Figura 23 - Resultado Rust-Analyze (parte 3) 51
 LISTA DE TABELAS

Tabela 1 — Regras de validação 40

Tabela 2 — Tabela de cores de resultado 51
Tabela 3 — Features do Rust Analyzer 52
Tabela 4 — Análise desacoplamento mapeado pela QGM, tabela comparativa
entre arquiteturas (Parte 1) 55
Tabela 5 — Análise desacoplamento mapeado pela QGM, tabela de
análise da implementação na visão da autora (parte 2) 56
Tabela 6 — Análise da arquitetura de acordo com
critérios do livro Domain-Driven Laravel 57
 LISTA DE ABREVIATURAS E SIGLAS

MVC Model View Controller

MVP Model View Present
EDA Event Driven Architecture
PDP Programer Data Processor
ES Engenharia de Software
HTTP Hypertext Transfer Protocol
CRUD Create, Read, Update, Delete
DB DataBase
API Application Programming Interface
ARC Atomically Reference Counted
SUMÁRIO
1 INTRODUÇÃO 13
1.1 MOTIVAÇÃO 15
1.2 OBJETIVOS GERAL 15
1.2.1 OBJETIVO ESPECÍFICO 15
1.3 ESTRUTURA DE TRABALHO 16
2 CONCEITOS GERAIS E PESQUISA APLICADA 17
2.1 ARQUITETURA DE SOFTWARE 17
2.2 PADRÕES ARQUITETURAIS 19
2.2.1 MVC 20
2.2.2 MVP 21
2.2.3 EDA 22
2.3 ARQUITETURA HEXAGONAL 23
2.3.1 ADAPTADORES 25
2.3.2 PORTAS 27
2.3.3 DOMÍNIO 28
3 FERRAMENTAS E METODOLOGIA 34
3.1 METODOLOGIA 34
3.1.1 VALIDAÇÃO DO PROJETO 35
3.2 FERRAMENTAS UTILIZADAS 33
3.2.1 DIAGRAMAS.NET 33
3.2.2 RUST 34
3.2.3 MONGODB 34
3.2.4 VISUAL STUDIO CODE 34
3.2.5 RUST ANALYZE 35
4 PROJETO 37
4.1 DESIGN DO PROJETO 37
4.2 ESTRUTURA DE PASTAS 40
4.3 IMPLEMENTAÇÃO 45
4.3.1 IMPLEMENTAÇÃO DO PROJETO 49
5 RESULTADOS 50
5.1 QUALIDADE DE CÓDIGO 49
5.2 DESACOPLAMENTO 55
5.3 ANÁLISE DA IMPLEMENTAÇÃO DA ARQUITETURA 56
5.4 PONTOS FRACOS E FORTES 57
6 CONCLUSÃO 58
REFERÊNCIAS 59
 12

1 INTRODUÇÃO

A década de 60 foi marcada pelo começo do negócio na área de software. Em 1960 a

DEC PDP-1 lançou o primeiro computador comercial (precursor do microcomputador), 1961
foi criado o primeiro vídeo game, desenvolvido por Steve Russel, em 1969 a CBS EVR
lançou o vídeo cassete, dentre outras inovações que aconteceram nessa década que
convergiram para que o termo "engenharia de software" fosse abordado em uma conferência
pela primeira vez com uma preocupação em ser evoluída, dado que software seria um novo
mercado. Assim, no ano de 1968, alguns autores abordaram o termo na NATO Conference on
Software Engineer, com o intuito de diferenciar a ciência da computação e a engenharia de
software (BARBOSA, 2009) .
Tendo em vista tais acontecimentos, houve um crescimento na importância da área da
computação responsável por construir sistemas (engenharia de software), e a preocupação
com a criação e evolução desses sistemas. No ramo da engenharia de software existem
algumas outras ramificações, que são estudadas dentro do escopo de engenharia, dentre elas, a
Arquitetura de Software (MAIER, 2001). A partir deste contexto, será abordado durante esse
trabalho de conclusão de curso, o ramo da engenharia conhecido como Arquitetura de
Software, que de acordo com alguns autores essa área é definida como:
Um conjunto de elementos arquiteturais (de dados, de processamento, de conexão) que
possuem alguma organização. Os elementos e sua organização são definidos por decisões
tomadas para satisfazer objetivos e restrições - (PERRY e WOLF, 1992)
Já para Shaw e Garlan, a arquitetura define o que é o sistema em termos de
componentes computacionais e, os relacionamentos entre estes componentes, os padrões que
guiam a sua composição e restrições - (SHAW e GARLAN, 1996) .
Por sua vez, 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).
A arquitetura de software é a organização fundamental de um sistema, representada
por seus componentes, seus relacionamentos com o ambiente, e pelos princípios que
conduzem seu design e evolução. O projeto da arquitetura é importante no processo de
 13

desenvolvimento, pois ele orienta a implementação dos requisitos de qualidade do software e

ajuda no controle intelectual sobre complexidade da solução. Além disso, serve como uma
ferramenta de comunicação que promove a integridade conceitual entre os stakeholders -
(VERGILIO, 2001).
Quando se fala em Arquitetura de Software é possível encontrar diversos tipos de
padrões e estilos de arquitetura, como model-view-present ou MVP (TAILIGENTE, 1990),
cliente-servidor ou client-server (KENDAL, 1953), MVC ou model-view-controller
(REENSKAUG, 1979), dentre outras e cada uma delas é utilizada para atacar um conjunto
particular de problemas dentro de um projeto de software, cenário ou contexto específico.
Em palavras simples, a arquitetura é uma das chaves para se obter o entendimento
intelectual sobre um sistema. Esse entendimento é provido pela 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).
Levando em consideração esse ponto, este trabalho será desenvolvido a partir de uma
solução mais "alto nível", ou seja, definindo contratos previamente e também desenvolverá a
arquitetura implementando esse design em "baixo nível", ou seja, criando uma aplicação que
siga aos padrões arquiteturais definidos. Será falado aqui do estilo arquitetural hexagonal,
criado e documentado por Alistar Cockburn em 2005, que tem o nome também de Ports and
Adapters e tem como objetivo desacoplar a camada de negócio de conexões com o mundo
externo, como com o cliente ou com conexões com banco de dados, com o objetivo de
facilitar o desenvolvimento da aplicação.
Essa arquitetura será implementada, a fim de entender como aplicar um dos seus
objetivos, o desacoplamento das camadas de código, que neste caso é separar as camadas de
negócio da infraestrutura, gerando um desenvolvimento e manutenção de software mais
eficiente.
Logo, nesse trabalho de conclusão de curso, será apresentado e aprofundado os
conceitos do padrão arquitetural hexagonal, em busca de trazer as nuances dessa arquitetura, a
partir de uma implementação prática utilizando os conceitos apresentados e sendo
 14

desenvolvida sobre esta arquitetura, isso porque esse estilo facilita em aplicações voltadas a
desenvolvimento backend e com a chegada o aumento das arquiteturas voltadas a
microservices esse design de código facilita também na implementação e comunicação de
projeto com outros ambientes .
O projeto será feito na linguagem de programação Rust, por ser uma linguagem que
autora teria interesse de aprender e trabalhar futuramente, para a implementação, o objetivo é
que seja possível entender e observar arquitetura hexagonal, considerando esse padrão para
gerar um desacoplamento no código e como falado anteriormente, facilitando a
implementação de estruturas que estão mais usadas atualmente.

1.1 Motivação

A motivação deste trabalho é buscar entender como o desacoplamento das camadas de

código podem facilitar na evolução do software, isso porque a medida que cada parte do
código tem sua determinada função fica mais fácil de adicionar ou remover recursos, e olhar
para o design de arquitetura hexagonal é um dos pontos para o desacoplamento do código,
para que isso tenha alcançado o devido êxito foi mapeado a estrutura do projeto antes da
implementação, para entender, de forma prática, como o processo de decisão arquitetural pode
beneficiar o desenvolvimento de sistemas.

1.2 Objetivo

O objetivo deste trabalho é implementar o padrão de Arquitetura Hexagonal com o

intuito de entender como ele favorece no desacoplamento do código a fim de avaliar como
essa arquitetura pode ajudar no desenvolvimento de software, utilizando a linguagem Rust.

1.2.1 OBJETIVO ESPECÍFICO

Os objetivos específicos deste projeto são divididos em 3 partes:

 15

● Verificar a qualidade de código através de ferramentas atuais;

● Entender a Arquitetura Hexagonal;
● Mapear os pontos fortes e fracos da implementação da Arquitetura Hexagonal.

1.3 Estrutura do trabalho

Esse documento está organizado em seis capítulos. O primeiro é introdução, que visa
contextualizar a pesquisa com suas motivações e objetivos. No segundo capítulo são conceitos
gerais aplicados, serão apresentados conceitos falados durante essa monografia e trazer
explicações mais aprofundadas sobre arquitetura hexagonal. No terceiro capítulo serão
apresentadas as ferramentas utilizadas durante a implementação deste projeto e qual
metodologia foi utilizada para a monografia. No quarto capítulo de desenvolvimento será
mostrado os principais fluxos de implementação. No capítulo cinco serão mostrados métricas
de sucesso e falhas aplicadas neste trabalho de conclusão de curso. Por fim, no sexto e último
capítulo é discutida a conclusão da pesquisa e também possíveis trabalhos futuros.
 16

2 CONCEITOS GERAIS E PESQUISA APLICADA

Neste capítulo, serão apresentados os conceitos básicos e definições do que é

arquitetura de software. Além disso, também será externado os conceitos da arquitetura
hexagonal, seu surgimento, como ela foi pensada e estruturada. Citar algumas outras
arquiteturas de forma breve para entender seu funcionamento. Também será falado sobre a
metodologia seguida durante esta monografia para validar a pesquisa e ter critérios de
avaliação de desacoplamento do código a partir do método GQM. Para a validação de
qualidade desta implementação será feito um estudo com ferramentas de qualidade de
software levando em consideração pontos definidos na Seção 2.5.2.

2.1 Arquitetura de Software

Esta seção tem o objetivo de mostrar que existem diversas definições e formas de
entender a arquitetura de um software, será falado sobre o conceito e surgimento da
arquitetura e qual visão será abordado durante este trabalho de conclusão de curso.  
Até a década de 90 o termo "arquitetura de software" já tinha sido citado algumas
vezes, contudo ainda não era um termo "comum" e que fosse importante até então ser
discutido sua definição, com o amadurecimento das linguagens de programação e a
preocupação em como fazer software de forma ágil e reutilizável, principalmente após a
década de 70 onde nessa década foi muito falado sobre criação de times que desenvolvessem
em larga escala, sobre gerência, dentre outras coisas, essas discussões geraram várias lacunas
em como construir software em larga escala (WIRTH, 2008).
Com o nascimento de muitas linguagens de programação, como C++ , que se tornou
importante para o surgimento de muitas outras e a preocupação de criar código e linguagens
mais interpretáveis, o termo "arquitetura de software" já era mais comum, contudo, a década
de 90 foi o momento onde houve o auge das discussões sobre a definição do que é arquitetura
de software e também como fazer com essa arquitetura ajudasse no desenvolvimento (SIM,
2005) . Existe um Padrão do que é arquitetura, de acordo com o Instituto de Engenheiros
 17

Eletricistas e Eletrônicos ISO/IEEE 1471-2000, que define a arquitetura com visões múltiplas
e se preocupa com os seguintes critérios :
● Todo Sistema tem uma Arquitetura mas nem toda arquitetura é um sistema.
● Uma arquitetura e uma descrição de arquitetura não são a mesma coisa.
● Padrões de arquitetura, descrições e processos de desenvolvimento podem diferir e ser
desenvolvidos separadamente.
● As descrições de arquitetura são inerentes e multi visualizadas.
● Separando conceitos de visão de um objeto para especificar caminhos de escrever
descrições de padrões de arquitetura.

Para além dos critérios estabelecidos pelo IEEE 1471, existem algumas definições sobre
arquitetura, são elas:
● É a interface entre o problema do negócio e a solução técnica (ASTUDILLO, 1998) .
● A Visualização do Processo, que contém a descrição das tarefas (processo e
encadeamentos) envolvidas, suas interações e configurações, e a alocação de objetos e
classes de design para tarefas. Esta visualização só precisará ser utilizada se o sistema
tiver um grau significativo de Simultaneidade. No RUP, ela é um subconjunto do
Modelo de Design (KRUCHTEN, 1995).
● Conjunto de componentes e seus relacionamentos, que deve satisfazer os requisitos
funcionais e não funcionais do sistema (MAIER, 2001)
● Implementar a arquitetura específica em um sistema, é se preocupar com o design,
como citado "o conceito de nível mais alto de um sistema em seu ambiente" (MAIER,
2001).

No artigo “An Introduction to Software Architecture”, é citado que a arquitetura de

software é um nível de design voltado para problemas: "Além dos algoritmos e das estruturas
de dados da computação; o design e a especificação da estrutura geral do sistema emergem
como um novo tipo de problema. As questões estruturais incluem organização total e estrutura
de controle global; protocolos de comunicação, sincronização e acesso a dados; designação de
funcionalidade a elementos de design; distribuição física; composição de elementos de design;
 18

escalação e desempenho; e seleção entre as alternativas de design." (GARLAN e SHAW,

1994) .
Logo, entender que, organização total e estrutura de controle global, andam juntos para
assim existir uma harmonia na implementação e que, o design está contido na arquitetura faz
com que, os pontos falados pelo autor seja importante para o desenvolvimento do software.
Tendo em vista os aspectos acima, é possível entender o esboço da "área" seguida neste
trabalho de conclusão de curso, tem o nome também de estilo ou padrão arquitetural, que é a
visualização arquitetural no projeto, este impõe um determinado grau de uniformidade à
arquitetura desenhada previamente.
A partir do entendimento sobre a definição de Arquitetura de Software serão falados
alguns padrões existentes atualmente, de forma breve, para que na sessão 2.3 seja falado e
aprofundado do padrão de arquitetura hexagonal.

2.2 Padrões Arquiteturais

O estilo pode ser definido por um conjunto de padrões, ou pela escolha de componentes
ou conectores específicos que funcionarão como os tijolos básicos da construção . Em um
determinado sistema, alguns estilos podem ser capturados como parte da descrição
arquitetural em um guia de estilo de arquitetura-fornecido por meio do produto de trabalho de
especificação do projeto. O estilo desempenha um papel vital na compreensão e integridade da
arquitetura. Esse será apresentado e destrinchando na proposta do artigo, definindo as
camadas que a arquitetura hexagonal exige pelo seu padrão (ANUNCIAÇÃO, 2006).

2.2.1 MVC

Nesse tópico será falado, de forma breve, sobre o padrão Movel-View-Controller (MVC),
esse padrão de projeto foi um dos primeiros criados e muito utilizados ainda hoje, o propósito
dessa arquitetura é dividir o projeto em três camadas, são elas:
 19

1. Model, onde será definido a camada de estrutura da aplicação, ela é responsável

também pela lógica de negócios e também pela leitura e manipulação de dados .
2. View, a principal responsabilidade dessa parte é a interação com o cliente, logo ela é
responsável por produzir interfaces de interação com o cliente.
3. Controller, ela é responsável pela ação do usuário, é a camada que faz a "gerência" ou
interface entre o Model e a view.

A imagem abaixo exemplifica como são separadas as camadas de uma arquitetura MVC:

Figura 1 — Model View Controller

Fonte: https://stackoverflow.com/questions/29594105/mvc-is-it-model-to-view-or-controller-to-view
 20

Não será aprofundada de forma específica essa arquitetura entrando em suas nuances,
pois o objetivo de trazer esse formato de arquitetura aqui é fazer uma comparação entre a
arquitetura hexagonal e o padrão MVC, para entender a partir dela, quais os pontos positivos e
negativos no desacoplamento de código.

2.2.2 MVP

A arquitetura MVP (Model-View-Present) é uma evolução da arquitetura MVC, nesse

padrão a View se comunica com o Present , onde serão enviadas ocorrências da interface
gráfica . Logo o MVP desacopla mais as funções que o MVC. Conforme representado na
imagem abaixo:

Figura 2 — Model View Present

Fonte: Elaborado pela autora.

 21

A função do Present é essencialmente o Controller do MVC, a única diferença é que ele

não está conectado a view, apenas a uma interface que se comunica com ela, com isso não

existe mais um tráfego direto da view.

2.2.3 ARQUITETURA ORIENTADA A EVENTOS

Esse estilo arquitetural é chamado EDA(Event driven architecture) , é popular em

sistemas assíncronos e distribuído, é uma arquitetura que traz consigo um desacoplamento de
código por cada face se comunicar com um serviço. Conforme representa a imagem abaixo:

Figura 3 — Event Drive Architecture

Fonte : https://blog.matheuscastiglioni.com.br/eda/

Essa arquitetura traz consigo pontos positivos como escalabilidade, tolerância a falhas, e
processos desacoplados e de pontos de desvantagens são : inconsistência de informações, lidar
com erros, dentre outros.
 22

Não será aprofundada de forma específica cada arquitetura entrando em suas nuances,
pois o objetivo de trazer esse formato de arquitetura aqui é fazer uma comparação entre a
arquitetura hexagonal e outros padrões arquiteturais, para entender a partir deles, quais os
pontos pontos fortes e fracos da arquitetura hexagonal.

2.3 Arquitetura Hexagonal

A arquitetura hexagonal foi criada e documentada em 2005 por Alistair 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, como objetivo principal, 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).
O conceito de Arquitetura Hexagonal, surgiu como uma proposta de evolução da
arquitetura limpa (clean architecture), uma arquitetura proposta por Robert Cecil Martin, que
tem o objetivo de padronizar e organizar o código desenvolvido, para que haja reusabilidade
independente da tecnologia, como notado na explicação a arquitetura limpa é muito parecida
com a arquitetura hexagonal, existem muitas discussões a respeito das duas arquiteturas e qual
a evolução da arquitetura hexagonal em relação a arquitetura limpa, nesta seção será abordado
e explicado mais detalhadamente sobre os conceitos da arquitetura hexagonal, não entrando
em divergências e convergências comparativas das duas arquiteturas.
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). E a solução proposta de portas e adaptadores, segundo o autor, é desacoplar
essas camadas e assim essas partes poderem ser criadas e testadas de forma independente.
Para entender mais sobre os principais módulos da arquitetura hexagonal, ela divide as
classes do sistema em dois principais grupos, que são eles:
● Classes de domínio, isto é, diretamente relacionadas com o negócio do sistema
(COCKBURN, 2005).
 23

● Classes relacionadas com infraestrutura, tecnologias e responsáveis pela integração

com sistemas externos assim como bancos de dados (COCKBURN, 2005).

Neste trabalho será referido a arquitetura hexagonal também como Portas e

adaptadores, isso porque Cockburn tentou renomear o nome de sua arquitetura para
Arquitetura baseada em Portas e Adaptadores, com a seguinte justificativa, falada em uma
entrevista:

"Eu finalmente tive esse momento aha! No qual vi que as faces do hexágono [interno]
são portas… e os objetos entre os dois hexágonos são adaptadores e, portanto, o padrão
arquitetural consiste em uma Arquitetura Baseada em Portas e Adaptadores. Esse nome
admite uma explicação melhor do que aquela que eu propus com o nome Arquitetura
Hexagonal" ( COCKBURN, 2005).

Logo é visível que o foco da arquitetura de portas e adaptadores é fazer com o core da
aplicação seja o principal aspecto a ser olhado no sistema, sendo ele desacoplado de todo o
sistema não gera impacto modificá-lo ou atualizado, fazendo com que regras de negócio sejam
facilmente aplicadas, sem interferir na infraestrutura utilizada no projeto.
O autor cita a arquitetura hexagonal como um caso "genérico" de um modelo em
camadas, o principal objetivo do pensamento de Alain Cockburn para a arquitetura de ports e
adapters é ver todo o contato externo como "semelhante" para dentro do aplicação, o autor
cita:
"Para mim, não há nada muito diferente sobre a rede e o banco de dados em
comparação com a pessoa sentada na tela trabalhando na interface do usuário. Na verdade,
eu deliberadamente desejo que haja pouca diferença. Eu quero especificamente substituir a
pessoa sentada na tela por um arquivo simples cheio de casos de teste, com um link EDI para
o computador de outra empresa, com um desenvolvedor digitando na janela de transcrição,
com um link para outro programa local. Além disso, desejo substituir a rede e o banco de
dados por um script enlatado ou banco de dados de demonstração localmente, com uma GUI
e um desenvolvedor inventando dados em tempo real, com um link de satélite." (Cockburn,
2006)"
 24

No livro "Domain-Driven Laravel" o autor especifica alguns pontos fortes da

arquitetura hexagonal :
"A abordagem hexagonal, quando executada corretamente, traz consigo
benefícios como os seguintes:
• Manutenibilidade;
• Adição de features rápidas;
• Alterações no código que não afetam outro código;
• Mais fácil e rápido de adicionar recursos, exigindo menos código para torná-los
função;
• Mais componentes separados;
• Código pouco repetido."
(GRIFFIN, 2021)

Os pontos levantados pelo autor acima serão analisados durante a implementação

dessa arquitetura no projeto e levados em conta na hora dos resultados. Nas sessões seguintes
serão apresentadas as camadas da arquitetura hexagonal e como elas são feitas para que haja
esse desacoplamento de camadas.

2.3.1 ADAPTADORES

O primeiro conceito que será definido na arquitetura hexagonal é dos adaptadores, eles
estão na camada mais externa da arquitetura, esses atuam como conectores do ambiente
externo com a aplicação, os adapters tem a seguinte função :
● 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).
● Também estão escutando chamadas de dentro do sistema, isto é, após passar pelo
domínio uma porta pegará esse dado que enviará essa chamada final para o adaptador
de saída e direciona para um sistema externo, como por exemplo um banco de dados
ou uma fila (EVANS, 2015).
 25

● Os adaptadores podem ser facilmente substituídos, por não possuir contato direito com
outras camadas de código, facilitando a mudança de infraestrutura sem causar um
impacto significativo ao projeto (EVANS, 2015).
● Um adaptador pode ter várias portas conectadas a ele, eles são usuários das portas.
● Os adaptadores têm também a função de persistir informações (EVANS, 2015).

Como mostra a figura abaixo, a idealização dos adaptadores é ser desacoplado de

qualquer camada do sistema, assim eles são facilmente conectados com outras portas. As
portas de saída vão ler dados, salvar informações, contudo é dentro dos adaptadores que serão
geradas as conexões com sistemas externos.

Figura 4 — Adaptadores Arquitetura Hexagonal

Fonte :
https://medium.com/ssense-tech/hexagonal-architecture-there-are-always-two-sides-to-every-s
tory-bc0780ed7d9c
 26

Para cada porta que seu hexágono possui, um adaptador deve ser criado, portanto, isso
traz a liberdade de modificá-lo e apagá-lo dinamicamente. Em portas e adaptadores, temos
também o conceito de portas primárias e secundárias, e o conceito é o mesmo utilizado com
os atores (COCKBURN, 2006).

2.3.2 PORTAS
As portas nasceram como interfaces das camadas mais baixo nível expostas, o termo
porta designa a entrada para a comunicação, e dentro da arquitetura hexagonal, a porta é
justamente essa camada de comunicação com a classes do domínio, a porta servirá como uma
interface e se refere a uma camada de abstração, entre o adaptador e o domain, que tem a
função de não deixar que o adaptador e domain se comuniquem,assim como ilustra a imagem
a seguir:

Figura 5 - Camadas da Arquitetura Hexagonal

Fonte : https://www.bclaud.com.br/posts/basics-hexagonal-architecture/
 27

No hexágono inferior a porta é representada como uma interface que traz o isolamento
do domain, nela que será feito o tratamento dos dados que entram no domain, em uma
Arquitetura Hexagonal, o termo porta designa as interfaces usadas para comunicação com as
classes de domínio (veja que interface aqui significa interface de programação)
Existem dois tipos de portas para a estrutura desta arquitetura:
● Portas de entrada (inbound): são portas usadas para transmissão de fora para dentro,
ou seja, quando um agente ou classe externa precisa chamar um método de uma classe
de domínio. Logo, essas portas declaram os serviços providos para o mundo exterior
(GAITONDE, 2020).
● Portas de saída: são interfaces usadas para comunicação de dentro para fora, isso
significa, quando uma classe de domínio precisa chamar um método de uma classe
externa. Logo, essas portas declaram os serviços requeridos pelo sistema, isto é,
serviços do mundo exterior que são necessários para o funcionamento do sistema
(GAITONDE, 2020).

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).
É de importância ressaltar que as portas na arquitetura hexagonal sempre serão
independentes de tecnologia, ou seja, para que o design esteja atendendo as expectativas, as
portas não devem depender de tecnologia, por isso elas já estão localizadas no hexágono
interior ( como é ilustrado na figura 5) .

2.3.3 DOMÍNIO

A última parte que falaremos dentro do padrão de design de Portas e Adaptadores é a

camada de domínio. Esta camada é a parte responsável por trazer a lógica de negócio, as
classes de domínio não devem depender de classes relacionadas com infraestrutura,
tecnologias ou sistemas externos (CockBurn, 2005). Então esse é um ponto que foi avaliado
enquanto o desenho do software e durante o período de desenvolvimento.
 28

Uma das vantagens da implementação da arquitetura hexagonal é também a mudança

da lógica do domínio, caso seja necessário no contexto do projeto, de forma eficaz, trazendo
essa divisão é desacoplar os dois tipos de classes (GRIFFIN, 2021). Abaixo é possível
classificar, segundo o autor, o que deve existir na camada do domain:

● Responsável por se referir a toda lógica de negócio, seja como essas regras estejam
implementadas. (GRIFFIN, 2021)
O desenho da arquitetura para representar o domínio está representado no centro do
hexágono:

Figura 6 — Princípios e Exemplos

Fonte :
https://itnext.io/hexagonal-architecture-principles-practical-example-in-java-364bb2e50075?g
i=154fdc7cb2d8

Em suma, como mostra a imagem acima, o domain está no centro da arquitetura

hexagonal, ele deve ser totalmente desacoplado de partes de código que refere a infraestrutura
ou transformações que são responsabilidade das portas, dentro dele deve haver apenas lógicas
 29

referente a validação de negócio e lógica, sendo um fator importante para mudar de forma
eficiente a lógica de negócio.

No capítulo seguinte serão apresentadas as ferramentas utilizadas para fazer esse

projeto de conclusão de curso e explicar a metodologia seguida para o mesmo.
 30

3 FERRAMENTAS E METODOLOGIA

Neste capítulo será mencionado quais ferramentas foram utilizadas para implementar a
arquitetura hexagonal, e a metodologia utilizada durante este trabalho, como falado
anteriormente, o objetivo deste trabalho é implementar esse design de arquitetura, o uso
dessas ferramentas atualmente são utilizadas pela indústria e por isso foram escolhidas para
este trabalho de conclusão de curso:

● DIAGRAMAS.NET desenhar arquitetura do projeto;

● RUST desenvolver o projeto;
● MONGODB desenvolver o projeto ;
● VISUAL STUDIO CODE desenvolver o projeto;
● RUST ANALYSE revisão de código;

3.1 Metodologia

A metodologia proposta para essa monografia foi uma prova de conceito e o objeto de
estudo foi uma implementação para entender conceitos da arquitetura hexagonal, sendo
analisada a partir de métricas qualitativas que resultem em entender pontos fortes e fracos da
implementação.
 31

3.1.1 VALIDAÇÃO DO PROJETO

Existem várias técnicas de avaliação e análise arquiteturais. Algumas técnicas avaliam

alguns detalhes da arquitetura fazendo comparativos entre duas propostas arquitetônicas para
definir qual se aplica melhor aos requisitos. Outras avaliam, de uma forma global, uma única
arquitetura para determinar se a arquitetura proposta possui os atributos de qualidade
necessários (BEZERRA, 2016).
A partir do ponto de vista, falado anteriormente, para validar a implementação da
arquitetura hexagonal e entender seus pontos fracos e fortes, foi utilizado a metodologia GQM
(goal, question, metric) que é uma forma metrificação de sucesso de um software, ela é
destrinchada de acordo com a imagem abaixo:

Figura 9 — Goal Question Metric

Fonte:https://www.geeksforgeeks.org/goal-question-metric-approach-in-software-quality/

Essa forma de análise, busca entender objetivos principais e a partir deles criar ramos
que tragam dúvidas e a partir daí métricas para medir o sucesso da implementação. Neste
trabalho será utilizado esse conceito para apresentar métricas de sucesso deste trabalho .
Para a análise do design do projeto e desacoplamento, foram levados em considerações
os os seguintes objetivos (Goals) de acordo com a metodologia GQM:

1. Garantia de Integridade de código

Para garantia de integridade de código foi utilizada uma ferramenta chamada
Rust-Analyze que tem como objetivo prevenir possíveis erros, remover códigos que não estão
 32

sendo utilizados e seguir boas práticas de desenvolvimento da linguagem Rust, esse ponto foi
definido como importante porque melhora a eficiência no tempo de compilação do projeto e
impede possíveis bugs no desenvolvimento.

2. Desacoplamento de design de código

No ponto de desacoplamento de código foram analisados dois critérios, como a arquitetura
hexagonal se comporta em relação a outras arquiteturas e em relação a sua implementação.

Esses pontos foram destrinchados em question (perguntas), sendo elas:

● Cada classe tem uma responsabilidade única ?
● As interfaces implementadas são independentes?
● Existem funções reutilizáveis no código?
● Os nomes das funções e variáveis trazem clareza?

Por fim, o último ponto destrinchado foram as metrics (métricas), sendo elas:
● Em questão de desacoplamento de código foram utilizadas as seguintes métricas: em
relação a outras arquiteturas, no ponto de vista de baixo acoplamento do design, pouca
dependência de módulos, funções com responsabilidade única e reutilização de
código, que serão apresentados na seção de resultados, foi observado também
desacoplamento de código em relação a aplicação seguindo critérios de todas as
interfaces serem utilizadas no código, o domain só tem regra de negócio e a porta
aponta pro domain e os adapters para as portas.
● Na qualidade de código foram utilizadas as seguintes métricas : não existir código não
utilizado, não existir if e elses que não são necessários, destacar breakpoints, remover
vírgulas e importações triviais.

Cada uma dessas perguntas serão analisadas na seção de Resultados (tópico 5) , de

acordo com as métricas apresentadas na mesma seção a fim de entender pontos fortes e fracos
da implementação da arquitetura hexagonal.
 33

Foi feita uma análise entre as arquiteturas citadas na seção 2.3 e a arquitetura
hexagonal, olhando para o ponto de desacoplamento de software metrificadas pela ferramenta
GQM.
Outra análise feita, na implementação de código, foi analisar pontos de sucesso de
uma implementação hexagonal segundo o livro Domain-Driven Laravel, esses pontos foram
abordados na seção 2.3 desta monografia.
O último ponto analisado, foi a qualidade do código, utilizando a ferramenta
Rust-Analyze a fim de validar boas práticas no código, a partir de métricas utilizadas por essa
ferramenta.

3.2 Ferramentas utilizadas

A escolha das ferramentas deu-se por conveniência em relação ao nível de proficiência

do autor. A seguir, serão apresentadas breves descrições sobre cada uma delas.

3.2.1 DIAGRAMAS.NET

O diagramas.net é uma ferramenta online de desenho gráfico de código aberto,

fundada em 2000 por Gaudenz Alder e David Benson, sua função é a criação de fluxogramas,
UML, desenhos de arquiteturas. Essa ferramenta foi utilizada neste trabalho para criação da
arquitetura hexagonal, fluxograma para explicar de forma representativa cada face da
arquitetura e trazer o exemplo da implementação.

3.2.2 RUST

Rust é uma linguagem de programação multiparadigma compilada desenvolvida pela

Mozilla. Ela foi utilizada para o desenvolvimento desse projeto, foi utilizado dentro dessa
linguagem algumas bibliotecas, como Tokio e Axum para acelerar o desenvolvimento.
 34

O rust não utiliza garbage collection, os valores armazenados em variáveis são

colocados na "queue memory" isso faz com que, assim que utilizados, essas variáveis irão
sumir.
Serão mostradas algumas definições básicas sobre a linguagem, que terão importância
no tópico a respeito da implementação do projeto, são elas:

1. struct - funciona como uma estrutura de tupla onde é definido o nome do

campo::valor.
2. trait - funciona como uma função abstrata que é uma interface.
3. ARC - "Atomically Reference Counted" essa estrutura é responsável por alocar os
valores na memória heap, o retorno dele é um ponteiro endereçando onde está aquele
valor na memória.

3.2.3 MONGODB

O MongoDB é um software de banco de dados orientado a documentos, de código

aberto e multiplataforma. Classificado como um programa de banco de dados NoSQL, que
utiliza o BSON (semelhante ao JSON) com esquemas.
O Mongo foi utilizado para criar as coleções que serão chamadas durantes no projeto
para salvar informações vindas de requisições HTTP, ele teve a principal função no projeto de
demonstrar o desacoplamento dos códigos quando é feito uma requisição e uma chamada no
banco de dados.

3.2.4 VISUAL STUDIO CODE

O Visual Studio Code é um editor de código-fonte desenvolvido pela Microsoft para

Windows, Linux e macOS. Ele inclui suporte para depuração, controle de versionamento Git
incorporado, realce de sintaxe, dentre outras funções que ajudam no desenvolvimento de
código. O Visual Studio Code foi utilizado junto com algumas extensões que existem dentro
dele para facilitar o desenvolvimento do código.
 35

3.2.5 RUST Analyze

Foi utilizado um plugin chamado Rust-analyze, que é feito para verificar a qualidade
de implementação de código e mapear melhorias na estrutura e remover códigos que não são
utilizados a fim de prevenir possíveis erros e gasto de memória .
 36

4 PROJETO

Neste capítulo será apresentado como o projeto foi criado para representar uma
arquitetura hexagonal, explicar decisões arquiteturais e design do código, mostrar diagramas
UML criados para implementar essa arquitetura e como houve o desacoplamento a nível de
código esclarecendo como esse desacoplamento pode beneficiar no desenvolvimento de um
projeto de software, na sessão seguinte será apresentado o resultado das pesquisas feitas sobre
a arquitetura, validando se o projeto desenvolvido de fato segue padrões arquiteturais
estabelecidos pelo design de portas e adaptadores.
Este projeto foi pensado e desenvolvido de forma autoral, sendo projetado de acordo
com estudos e leituras da arquitetura hexagonal, colocando em prática os conceitos principais
falados durante todo este projeto de conclusão de curso, estes conceitos foram explicitados no
capítulo referentes ao 2.3, onde se fala da arquitetura hexagonal.
Atualmente, a autora tem cerca de 6 meses de experiência de implementação da
arquitetura hexagonal dentro do ambiente de trabalho, para além disso, cerca de 3 meses
estudando profundamente os conceitos desta arquitetura para a conclusão deste trabalho,
lendo artigos, vendo vídeos e propostas do autor.
O projeto desenvolvido para apresentar a arquitetura hexagonal foi uma API REST
com os eventos de leitura, escrita, adição e remoção de campos utilizando o Banco de dados
MongoDB, esse sistema faz chamadas HTTP e salva essas informações no banco a partir de
algumas regras de negócio definidas no tópico 4.1 deste documento.

4.1 Design do Projeto

Nesse tópico será falado como foram tomadas as decisões a respeito do design do
projeto, essa foi uma sessão de análise de requisitos, onde foi pensado como o fluxo
funcionaria a fim de seguir aos critérios estabelecidos pela arquitetura hexagonal.
 37

O fluxograma criado a princípio foi um "esboço" de como utilizar a arquitetura

hexagonal, como segue imagem a seguir:

Figura 10 — Fluxo da Arquitetura Hexagonal

Fonte: Elaborado pela autora.

Como observado acima, a ideia pensada foi trazer duas conexões externas, uma do lado
do cliente, outra do lado do servidor de banco de dados, essas estruturas foram pensada para
demonstrar que ao serem implementadas na camada de adapter elas são além de desacopladas
de fácil "troca" por exemplo, caso fosse necessário mudar o banco de dados escolhido ou
utilizar dois bancos em uma aplicação bastaria adicionar um adapter novo a essa conexão.
Logo a primeira decisão de projeto foi que seriam dois adapters, sendo assim:

● HTTP Request (entrada do mundo externo),

● Banco de Dados (utiliza e armazena arquivos de um servidor),
 38

Foi utilizado adaptadores de entrada do tipo HTTP e de saída uma conexão com o banco
de dados a fim de apresentar a estrutura de entrada e saída do fluxo de dados.

O segundo ponto pensado foi em um projeto para implementar e validar o sistema. Para
isso foi pensado em uma API de cadastro, leitura, edição e remoção de livros para que
trouxesse uma ideia de projeto real. A partir da definição do que seria feito, foram mapeados
pontos para que durante a implementação fosse possível atender aos critérios de cada camada
da arquitetura hexagonal.

Foram mapeadas as regras abaixo com o objetivos de atender ao design de portas e

adaptadores dentro da implementação:

Tabela 1 - Regras de validação

Camada Critério

Adapter Dentro do adapter existirão dois módulos .

1. Para as requisições HTTP (entrada);
2. Para as chamadas do Banco de
Dados (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 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 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
 39

default é false) para ser enviado para porta

de saída para o BD;

Fonte: Elaborado pela autora

É importante ressaltar que não foram levados em consideração durante a implementação

do projeto possíveis erros e tratamento dos mesmos ou regras robustas de negócio, isso porque
a implementação tem um fim único de apresentar a arquitetura hexagonal.

Para a validação dos requisitos comentados acima, foram projetados payloads esperados
que passaram pelas camadas de adapter, ports e domain da aplicação. Esses payloads também
foram pensados a fim de implementar a arquitetura hexagonal, com o objetivo de atender aos
critérios definidos na tabela 1 e também para atender a cada camada da aplicação, os
payloads são:

Figura 11-[Port inbound] Payload de Entrada HTTP - POST

Fonte: Elaborado pela autora

 40

É importante observar que no primeiro momento, o usuário fará uma requisição do tipo
POST com o nome do livro como "name". O payload de entrada nas regras de negócio para o
nome do livro é "book_name". Seguindo o seguinte exemplo :

Figura 12- [Domain] Payload de Entrada no Domain

Fonte: Elaborado pela autora

Para salvar no Banco de dados o Payload que é utilizado na Port, tem um parâmetro a
mais o "_id", que tem um valor único gerado pelo próprio MongoDB, no Domain esse valor é
um Option, abaixo terá um exemplo do payload de saída.

Figura 13 - [Port Outbound] Payload para salvar no Banco de Dados

 41

Fonte: Elaborado pela autora

Os resultados de implementação da arquitetura hexagonal, das estruturas mapeadas

acima, estarão na seção 5, onde será validado se o design do projeto segue o exemplo da
arquitetura hexagonal de acordo com critérios de sucesso estabelecidos.

4.2 Estruturas de Pastas

Nesta seção será explicado como foi desenvolvido o design arquitetural na

implementação, ou seja, será mostrado como foram definidos os nomes dos arquivos,
organização de pastas olhando para como é o padrão de uma implementação hexagonal.

4.2.1 Raiz do Projeto

Na pasta raiz do, terá o arquivo main.rs que tem a função de inicializar o projeto, onde
ficará a conexão com o servidor, a inicialização do banco de dados, as chamadas http.

Figura 14 — Estrutura de Pastas - main 

Fonte: Elaborado pela autora

 42

Na mesma camada do arquivo main.rs vai existir uma camada referente a estrutura de
pastas com os nomes utilizados pela arquitetura hexagonal, ports, adapters e domain. Esses
nomes foram utilizados para trazer clareza onde cada módulo do projeto está, seguindo o
padrão de nomenclatura utilizado por Cockburn, por que assim é fácil identificar cada parte da
arquitetura.

4.2.2 Fluxo de arquivos

1. Fluxo de arquivos

Após o source(src) foram criadas pastas onde estarão as camadas explicadas durantes
este trabalho de conclusão de curso, são elas os adaptadores(adapter), portas(ports), dominio(
domain) e configuração (config), como apresenta a figura 15.

Um dos objetivos da arquitetura hexagonal é o desacoplamento de código, logo, para

que fosse mais visível cada tipo de conexão dentro dessa arquitetura estrutural, foi criado uma
pasta falando qual o tipo de conexão que está sendo feito por camada, como por exemplo:
uma conexão http ou de banco de dados (como foi utilizado no projeto), assim como poderiam
ter outras conexões como com filas . Como ilustra a figura 15, na camada de adapter, tem
uma subpasta onde fala se ela é do tipo inbound (vinda do mundo externo) e dentro dela o tipo
de chamado para que haja o arquivo com as chamadas que tem relação com o tipo de conexão.
No caso em exemplo é uma chamada do tipo HTTP, e lá terá chamadas relacionadas ao
adapter, como no projeto foi feito um CRUD, as requisições serão de GET, POST, CREATE,
DELETE do projeto de livro.
 43

Figura 15 — Estrutura de Pastas - arquivos

Fonte: Elaborado pela autora

Assim, como representado na figura 14 a relação de cada camada explicada pela

arquitetura hexagonal está no source, ou seja, a pasta de adaptador, portas e domain vem de lá
e dentro de cada um desses arquivos existe uma camada de entrada e saida (inbound and
outbound) e dentro deles a pasta referente a cada tipo de adaptador, como refere-se a figura
15, seguindo assim a proposta do autor, Alistar Cockburn para a representação da arquitetura.

Essa estrutura de pastas foi pensada a fim de desacoplar os arquivos e os tipos de

chamadas feitas na implementação, foi feito um estudo a fim de entender os pontos fortes e
fracos desse design de código na seção de Resultados.
 44

4.3 IMPLEMENTAÇÃO

Aqui serão apresentadas algumas funções implementadas que mostram o desacoplamento

do código e o fluxo que acontece na arquitetura hexagonal, é possível encontrar a
implementação completa no repositório do github.

● Main

O main tem a função de inicializar o projeto, lá onde ficará a inicialização da porta que
roda o serviço, o servidor e do Banco de dados e a inicialização referentes ao projeto.

● Adapters

A primeira camada de entrada após a inicialização é o adapter, que será o contato do

"mundo externo" com sua aplicação, onde acontece, no caso da imagem a seguir, as chamadas
HTTP, ou seja, os fluxo de endpoint de create, update e delete estarão na camada de adapter.

Figura 16 — Exemplo de Adapter na Arquitetura Hexagonal

pub async fn create(

Json(payload): Json<CreateBook>,
Extension(state): Extension<Arc<MongoRepo>>,
) -> impl IntoResponse {
let book = transform_inbound_to_domain(payload);
let book_out = transform_domain_to_outbound(book);
(StatusCode::CREATED, Json(book_out.unwrap()))
}

Fonte: Elaborado pela autora

 45

A Figura 16 é um exemplo onde o módulo de adapter chama a função

transform_indoud_to_domain(), que recebe o payload de entrada e o envia para a camada de
port, lá que existirá a interface de tradução do que é recebido do mundo externo para a lógica
de negócio, que será falado a seguir.

Foi criado outro adaptador no projeto, que foi o adaptador de saída que é o que faz a
conexão com o banco de dados, como representado na figura 17:

Figura 17 — Exemplo de Adapter na Arquitetura Hexagonal

fn create(&self, new_book: Book) -> Result<InsertOneResult, Error> {

let new_doc: Book = new_book;
let book = self
.col
.insert_one(new_doc, None)
.ok()
.expect("Error creating user");

Ok(book)
}

Fonte: Elaborado pela autora

É possível perceber através dessa implementação que os adaptadores representados acima

tem apenas o primeiro a função de fazer uma requisição POST (criação) e o segundo criar
aquela informação no banco de dados, dentro deles não é esperado que se faça nada além
disso, como proposto na arquitetura hexagonal.
 46

● Ports

O exemplo abaixo é uma função existente na camada de porta inbound, ela acontece após
o estímulo do adapter, ou seja, no caso que está sendo apresentado o fluxo, após uma chamada
HTTP o adapter chamará uma porta responsável por ser a interface da arquitetura e assim
traduzir o que vem do mundo externo pro domain.

Figura 18 — Exemplo de Portas na Arquitetura Hexagonal

#[derive(Serialize)]
pub struct Book {
pub id: Option<Uuid>,
pub book_name: String,
pub description: String,
pub is_test: bool,
}

pub fn transform_inbound_to_domain(payload : CreateBook) -> BookDomain{

let book = book_domain::BookDomain {
id: None,
book_name: payload.name,
description: payload.description,
is_test: false,
};

let result_book: book_domain::BookDomain = book_domain::validate_field(book) ;

result_book
}

Fonte: Elaborado pela autora

 47

O exemplo de código mostrado acima espera um payload do tipo, CreateBook ( que vem
da camada Adaptadora ) , após entrar na porta a função validate_field direciona esse payload
pro domain (após convertido numa struct esperada pelo domain), ao fazer as validações
necessárias, que foram comentadas na tabela 1, será retornado o result_book que veio do
Domain.

● Domain

No último fluxo da arquitetura, a camada de domain, é responsável pelas regras de

negócio. Como mostra o exemplo abaixo :

Figura 19 — Exemplo de Domain na Arquitetura Hexagonal

pub struct BookDomain {

pub id: Option<String>,
pub book_name: String,
pub description: String,
pub is_test: bool,
}

pub fn validate_field(book: BookDomain) -> BookDomain {

if book.book_name == "livro teste" {
let book_field = BookDomain {
id: book.id,
book_name: book.book_name,
description: book.description,
is_test: true,
};

return book_field;
 48

book
}

Fonte: Elaborado pela autora

Assim como falado anteriormente, para mostrar que essa camada é responsável pela regra
de negócio e é desacoplada do que vem da entrada do mundo externo, foi feito um exemplo
simples para definir se o livro é ou não do tipo "is_test", essa camada recebe o tipo
BookDomain, e retorna o tipo BookDomain, que será utilizado pela próxima porta que utilizar
esse serviço.

Nesse ponto é importante salientar que o domain não tem contato direto com outras
camadas do código, ele apenas interage validando as regras de negócio, e retornando um
objeto do tipo domain, cumprindo assim o que é estabelecido pela arquitetura hexagonal, que
o domain tenha apenas essa responsabilidade.

4.3.1 IMPLEMENTAÇÃO DO PROJETO:

O projeto foi feito e armazenado no repositório do GitHub, e a implementação completa

da arquitetura pode ser encontrada no seguinte link :

https://github.com/estelasouza/tcc
 49

5 RESULTADOS

Para a pesquisa, foi utilizado o método GQM (goal, question, metric) a partir dele foram
encontradas métricas para medir os pontos de sucesso e de fracasso durante a implementação
utilizando a arquitetura hexagonal. Em resumo sobre esse método :

1. Goal - significa meta, esse ponto é responsável por visualizar os principais pontos do
projeto
2. Questions - significa perguntas, a partir das "metas" estabelecidas serão geradas
perguntas a respeito de como é possível metrificar o sucesso
3. Metric - significa métrica, aqui serão verificados de forma mais palpáveis métricas que
serão destrinchadas para atingir ao sucesso das principais metas.

Os seguintes pontos foram mapeados como sucesso nas metas :

 50

Figura 20 — GQM - Definição de métricas

Fonte: Elaborado pela autora

Os pontos citados acima serão analisados nas seções 5.1 e 5.2.

Para além do GQM foi utilizado a análise de sucesso de implementação da arquitetura

hexagonal feita pelo autor Jesse Griffin no livro Domain-Driven Laravel, onde ele avalia
pontos de sucesso de uma arquitetura hexagonal, será feita uma análise crítica por parte da
autora da implementação sobres esses pontos de sucesso ou melhoria.

● A avaliação de qualidade de código será feita a critério da ferramenta (Rust-analyzer)

e de responsabilidade de análise da própria autora.
● O julgamento do sucesso dos critérios de avaliação feitas para pontos de comparação
e análise da arquitetura foram colocados em 3 camadas, sendo elas :
 51

Tabela 2 - Tabela de cores de resultado

Nota Cor

Atendeu as expectativas

Abaixo das expectativas

Não atendeu as expectativas

Fonte: Elaborado pela autora

As cores representam a "nota" definida pela autora em cada ponto da avaliação, logo
as tabelas serão preenchidas por cores e essas representarão se o tópico atendeu as
expectativas, foi abaixo das expectativas ou não atendeu as expectativas.

5.1 Qualidade de código

Para analisar a qualidade de código, foi utilizado uma ferramenta chamada Rust-Analyze
que ao ser configurada analisa os seguintes critérios, esses foram estabelecidos no
mapeamento do método do GQM, logo foram ativadas as seguintes funcionalidades no
Rust-Analyze :

Tabela 3 - Features do Rust Analyzer

Funcionalidade Status

Remover código que não é necessário Ativado

Remove vírgulas e importações triviais Ativado

 52

Juntar linhas consecutivas entre ifs Ativado

Destacar breakpoints Ativado

Importar configurações para todos os Desativado

arquivos

Restartar o serviço automaticamente por Desativado

causa de alguma configuração

Fonte: Elaborado pela autora

A ferramenta tem como objetivo verificar a qualidade de implementação de código e

mapear caso exista melhorias na estrutura, prevenir possíveis erros e gasto de memória. Tal
ferramenta utiliza padrões de código do Rust para sugerir melhorias. No primeiro momento
que ela foi executada, surgiram warnings na estrutura de código, como mostra a figura 21 e o
resultado da compilação na figura 22:

Figura 21 — Resultado Rust-Analyze (parte 1)

Fonte: Elaborado pela autora

 53

Figura 22 — Resultado Rust-Analyze (parte 2)

Fonte: Elaborado pela autora

Foram feitas as alterações sugeridas pela ferramenta, para que essa análise acontecesse
novamente, é possível verificar que o tempo de compilamento da aplicação antes das
alterações foi de 0.61s , após a correção sugerida pela ferramenta, houve o seguinte resultado
no tempo de compilação:

Figura 23 - Resultado Rust-Analyze (parte 3)

Fonte: Elaborado pela autora

É perceptível que após a correção, houve um resultado de melhoria no tempo de

compilação do projeto, diminuindo significativamente, de 0.61s para 0.22s, isso significa que
essas melhorias otimizaram a execução do projeto.

A partir dessa conclusão, nota-se que após a melhoria do código, houve um ganho
considerável no tempo de execução do projeto, após sugestão do Rust Analyze.
 54

É importante ressaltar que, essa ferramenta traz a análise de forma geral e não uma
definição mais cognitiva, então essa avaliação está sujeita a falhas por levar em consideração
apenas pontos pré-mapeados, outro ponto, é que qualidade de código foi levada em
consideração apenas a opinião da autora, podendo ser tendenciosa, então existe um ponto de
melhoria para trabalhos futuros.

Após a análise dos pontos levantados é possível avaliar que dentro dos pontos levantados
atualmente a qualidade de código atende as expectativas de padrão definidas pela ferramenta.

5.2 Desacoplamento

Foi feita uma comparação entre as arquiteturas apresentadas na seção 2, são elas a MVC,
MVP e Arquitetura Orientada a Eventos, para entender quais critérios mapeados no GQM
cada arquitetura abrange, com o intuito de tirar conclusões delas em relação à arquitetura
hexagonal.

Tabela 4 - Análise desacoplamento mapeado pela QGM, tabela comparativa entre arquiteturas
(Parte 1)

PERGUNTAS MVC MVP ARQUITETUR ARQUITETUR

A ORIENTADA A
A EVENTOS HEXAGONAL

Baixo acoplamento do
design de código
(estrutura de pastas)

Pouca dependência de
módulos da aplicação

Funções com
responsabilidade única
 55

Reutilização de código
Fonte: Elaborado pela autora

Na análise comparativa referente a tabela 4 é importante deixar mapeado que cada

arquitetura tem seu design definindo escopos que resolvem problemas específicos, a escolha
desses estilos arquiteturais foram feitos a critério da autora, tenso o risco de ser enviesado por
não estar olhando a implementação de outras arquiteturas, se não dá hexagonal, sendo assim,
tais comparações demonstram a efetividade da arquitetura hexagonal em questões de outras
arquiteturas tendo em vista o seu escopo da implementação hexagonal e experiência da autora
para a comparação, como falado anteriormente, em projetos de softwares que são atuais,
voltados a desenvolvimento de microsserviços e desenvolvimento backend.

Tabela 5 - Análise desacoplamento mapeado pela QGM, tabela de análise da implementação

na visão da autora (parte 2)

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 outras partes do código;

A porta faz chamada apontando pro domain e os

adapters apontam pras portas;
Fonte: Elaborado pela autora

De forma breve, é perceptível o ganho na implementação na arquitetura hexagonal,

quando se fala em desacoplamento de código. Tendo em vista as arquiteturas MVC, MVP e
Orientada a Eventos. E ao falar em pontos específicos definidos como critério para
desacoplamento na implementação, de acordo com a autora, foi-se possível notar todos os
critérios de forma positiva na implementação.
 56

5.3 Análise da Implementação da Arquitetura

Na referente a implementação de arquitetura da arquitetura hexagonal, de forma geral,

no ponto de vista do autor Jessen Griffin, que tem a autoria do livro Domain-Driven Laravel.
Os critérios de sucesso de implementação citados no final do tópico 2.3 foram analisados e
julgados a critério da autora o quão a implementação feita atende aos pontos levantados pelo
autor em questão, para que a implementação da arquitetura hexagonal tenha ocorrido de
forma efetiva.

Tabela 6- Análise da arquitetura de acordo com critérios do livro Domain-Driven Laravel

CRITÉRIO IMPLEMENTAÇÃO

Adição de features rápido.

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

código.
 57

Mais fácil de adicionar recursos, exigindo

menos código para torná-los função.

Código pouco repetido.

Manutenabilidade

Fonte: Elaborado pela autora

É possível notar que nos 3 primeiros pontos sugeridos pelo autor Jessen, a
implementação atende aos critérios, no ponto de repetição de código, foi mapeado pela autora
desta monografia um ponto que não atende as expectativas como esperado, levantando o
seguinte cenário: se duas filas forem consumidas e utilizarem payloads com apenas 1 campo
diferente, será necessário criar duas portas separadas para cada fila. No ponto de
manutenibilidade, na visão da autora que desenvolveu o projeto, o ponto de manutenibilidade
não atinge as expectativas, como algo simples pois à medida que o projeto vá crescendo, a
manutenção vai ficar mais complexa por existir muitos arquivos.

5.4 Pontos Fracos e Fortes

A partir das análises feitas pela ferramenta Rust Analyze e pela própria autora é possível
ver que a implementação teve sucesso nos quesitos de qualidade de código e o tempo de
compilação após utilizar as sugestões da ferramenta caíram de 0.61s para 0.22s, logo no
seguinte ponto o projeto atendeu as expectativas.

No critério seguinte relacionado a desacoplamento, houveram duas avaliações:

 58

● A arquitetura hexagonal em relação às arquiteturas MVC, MVP e EDA a arquitetura

hexagonal 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 acabaram se saindo na frente.
● A avaliação pelos critérios da própria autora, onde foi possível notar sucesso nos
aspectos separação da camada de domain, interfaces que foram implementadas foram
utilizadas, e o fluxo de adapter apontar para porta e em seguida porta para domain.

O último ponto analisado foi a análise da arquitetura levando em consideração pontos

falado pelo livro 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. Nos pontos que deixaram a desejar na
arquitetura foram mapeados, código pouco repetido e manutenabilidade, explicados na seção
referente.

Por fim, é importante lembrar que os critérios foram avaliados pela autora em questão da
monografia, ou seja, não foi feita uma pesquisa quantitativa que mostrasse que os pontos
levantados pelo autor convergem com pontos vista da comunidade, tendo o risco de ter uma
análise tendenciosa, tal ponto é levantado para possíveis trabalhos futuros .

6 CONCLUSÃO

Este trabalho de conclusão de curso teve como objetivo geral apresentar o padrão de
arquitetura hexagonal, que é chamado também de portas e adaptadores, e a partir da
apresentação desse padrão exibir a implementação de como utilizar essa arquitetura em um
projeto de software, pontuando como ela favorece o desacoplamento de código.
Foi possível durante o desenvolvimento do trabalho explicar de forma teórica
conceitos de arquitetura de software, mostrar visões de outras arquiteturas para além da
 59

hexagonal, como a MVP e MVC, aprofundar conceitos da arquitetura hexagonal e de forma

prática entender os requisitos para que a implementação do padrão de portas e adaptadores
para que fosse possível ter sucesso na implementação final. Também foram explicadas na
seção resultados como foram os critérios para validação da pesquisa e por fim visualizar
pontos fortes e fracos da implementação.

6.1 Riscos e Limitações

A partir do que foi levantado foi possível validar resultados a partir de métricas
utilizadas pelo Rust Analyzer, métricas geradas pela própria autora do projeto e também
métricas de sucesso conceituadas no livro Domain Driven Laravel, para ver resultados da
pesquisa.
Contudo, é de suma importância mapear o risco de uma análise tendenciosa tendo em
vista que o projeto em questão não teve pesquisas quantitativas que mostrassem a validade da
implementação através de dados, isso implicou em ter apenas critérios de sucesso de acordo
com a autora deste trabalho, sendo assim, importante pontuar a limitação pois não foi possível
fazer uma pesquisa mais profunda.
Outro ponto importante a se falar é que o projeto feito foi um projeto com intuito de
pesquisa para implementação, sendo assim um projeto com poucas regras de negócio e não
tendo um fim além de atender aspectos relacionados à arquitetura hexagonal.

6.2 Trabalhos Futuros

Para trabalhos futuros, o primeiro ponto levantado foi dar continuidade a esse trabalho
buscando fazer pesquisas quantitativas para entender outras visões e opiniões sobre a
qualidade de código e a implementação feita da arquitetura hexagonal, é factível também
entender como o comportamento dessa arquitetura em sistemas com larga escala, verificar
eficiência do projeto .
Para além desse ponto, a arquitetura hexagonal ainda é relativamente nova, não
existem tantos artigos ou trabalhos relacionados sobre a mesma, é possível também, para
 60

trabalhos futuros fazer revisões literárias sobre o assunto aprofundando em alguns pontos e
buscando lacunas de estudo nessa área da arquitetura de software.
 61

REFERÊNCIAS

N. Wirth. "A Brief History of Software Engineering," in IEEE Annals of the

History of Computing, vol. 30, no. 3, pp. 32-39, July-Sept. 2008, doi:
10.1109/MAHC.2008.33.

Cockburn, A. Hexagonal Architecture. 2014. Disponível em:

<http://wiki.c2.com/?HexagonalArchitecture>. Acesso em: 10 ago. 2022.

G. Booch. "The History of Software Engineering," in IEEE Software, vol. 35,

no. 5, pp. 108-114, September/October 2018, doi: 10.1109/MS.2018.3571234.

S. E. Sim, "A small social history of software architecture," 13th International

Workshop on Program Comprehension (IWPC'05), 2005, pp. 341-344, doi:
10.1109/WPC.2005.3.

Barbosa. G. Um Livro-texto para o Ensino de Projeto de Arquitetura de

Software. 2009. Disponível em:
<http://docs.computacao.ufcg.edu.br/posgraduacao/dissertacoes/2009/Dissertacao_Guilher
meMauroGerrmoglioBarbosa.pdf>. Acesso em: 9 out. 2022

Perry, Dewayne E. and Alexander L. Wolf. “Foundations for the study of

software architecture.” ACM SIGSOFT Softw. Eng. Notes 17 (1992): 40-52.

Bass L. Clements P. & Kazman R. Addison-Wesley. Software architecture in

practice (2nd ed.) (2003).
 62

Barroca, L., Hall, J., & Hall, P. (2000). An Introduction and History of Software
Architectures, Components, and Reuse. Software Architectures, 1–11.
https://doi.org/10.1007/978-1-4471-0367-7_1

Robert C. Martin. 2017. Clean Architecture: A Craftsman's Guide to Software

Structure and Design (1st. ed.). Prentice Hall Press, USA.

Gaitonde,A. Hexagonal Architecture- Principal & Practical example 2020.

Disponível em:
<https://itnext.io/hexagonal-architecture-principles-practical-example-in-java-364bb2e500
75>. Acesso em: 11 set. 2022

Bezerra I. M., Carla. "Medidas para avaliação e manutenibilidade do modelo de

features de linhas de produção de software tradicionais e dinamicas" 2016, Disponivel
em: <https://repositorio.ufc.br/bitstream/riufc/29447/3/2016_tese_cimbezerra.pdf>.
Acesso em: 09 set. 2022

M. W. Maier, D. Emery and R. Hilliard, "Software architecture: introducing IEEE

Standard 1471," in Computer, vol. 34, no. 4, pp. 107-109, April 2001, doi:
10.1109/2.917550.

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.
Philippe Kruchten 1995. "The 4+1 view model of architecture," IEEE Software.
12(6), novembro de 1995

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.

Gaitonde,A. Hexagonal Architecture- Principal & Practical example 2020.

Disponível em:
 63

<https://itnext.io/hexagonal-architecture-principles-practical-example-in-java-364bb2e500
75>. Acesso em: 11 set. 2022

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.
M. Shaw and D. Garrlan, Software architecture: perspectives on an emerging
discipline. Pretice Hall, 1996