The Codest
  • Sobre nós
  • Serviços
    • Desenvolvimento de software
      • Desenvolvimento de front-end
      • Desenvolvimento backend
    • Staff Augmentation
      • Programadores Frontend
      • Programadores de back-end
      • Engenheiros de dados
      • Engenheiros de nuvem
      • Engenheiros de GQ
      • Outros
    • Aconselhamento
      • Auditoria e consultoria
  • Indústrias
    • Fintech e Banca
    • E-commerce
    • Adtech
    • Tecnologia da saúde
    • Fabrico
    • Logística
    • Automóvel
    • IOT
  • Valor para
    • CEO
    • CTO
    • Gestor de entregas
  • A nossa equipa
  • Case Studies
  • Saber como
    • Blogue
    • Encontros
    • Webinars
    • Recursos
Carreiras Entrar em contacto
  • Sobre nós
  • Serviços
    • Desenvolvimento de software
      • Desenvolvimento de front-end
      • Desenvolvimento backend
    • Staff Augmentation
      • Programadores Frontend
      • Programadores de back-end
      • Engenheiros de dados
      • Engenheiros de nuvem
      • Engenheiros de GQ
      • Outros
    • Aconselhamento
      • Auditoria e consultoria
  • Valor para
    • CEO
    • CTO
    • Gestor de entregas
  • A nossa equipa
  • Case Studies
  • Saber como
    • Blogue
    • Encontros
    • Webinars
    • Recursos
Carreiras Entrar em contacto
Seta para trás VOLTAR
2023-06-13
Desenvolvimento de software

O poder da arquitetura hexagonal

thecodest

Explore o poder da Arquitetura Hexagonal para melhorar a capacidade de manutenção, testabilidade e adaptabilidade do software.

Neste guia completo, vamos aprofundar as nuances de Arquitetura Hexagonalexplorando a sua definição, componentes e história. Estabeleceremos comparações entre Arquitetura Hexagonal e outros padrões arquitectónicos populares para realçar os seus pontos fortes únicos. Além disso, examinaremos o seu papel fundamental na conceção orientada para o domínio (DDD) e microsserviçosque são cada vez mais importantes no mundo moderno desenvolvimento de software.

1. Introdução à Arquitetura Hexagonal

Na paisagem dinâmica do arquitetura de software, Arquitetura Hexagonal, também conhecido por Portos e Padrão de adaptadoresA União Europeia, que se tornou um candidato formidável, tem vindo a desafiar progressivamente as normas de arquitetura tradicional em camadas.

Impulsionada pela necessidade de uma conceção arquitetónica que pudesse garantir testes fáceis e uma maior facilidade de manutenção, Arquitetura Hexagonal foi concebido. A sua missão: fornecer serviços robustos aplicações informáticas livre das complexidades e inconstâncias do mundo exterior.

Ao longo deste artigo, vamos embarcar numa viagem pelos anais da Arquitetura Hexagonal - uma arquitetura que se situa no nexo entre simplicidade e poder. Iremos desvendar a sua história, estrutura e princípios, e compará-la com outras padrões arquitectónicos. Examinaremos o seu potencial para elevar a qualidade das aplicações de software e reduzir a maré crescente de dívidas técnicas que atormenta a indústria do software.

2. Definição de Arquitetura Hexagonal

No fundo, Arquitetura Hexagonal, ou os Portos e Arquitetura dos adaptadoresé um padrão de design baseado na segregação de preocupações. Divide uma aplicação em duas secções principais: a interna e a externa.

O interior, também designado por núcleo da aplicação, aloja o lógica empresarial e objectos de domínio - o núcleo de valor do seu software. Este santuário interno permanece separado de influências externas, preservando assim a integridade do lógica empresarial e o modelo do domínio.

O exterior, por outro lado, é o domínio dos sistemas externos - do interface do utilizador ao acesso à base de dados - que interagem com o núcleo da aplicação. Estas interações são geridas através de um mecanismo de portas e adaptadores, assegurando uma separação clara entre o núcleo da aplicação e os seus actores externos.

3. História da Arquitetura Hexagonal

Arquitetura Hexagonal é uma criação de Alistair Cockburn, um visionário que articulou pela primeira vez este conceito como uma resposta às limitações da arquitetura em camadas. Foi concebido para criar um sistema de camada de domínio que isola o núcleo lógica empresarial de influências externas, como o interface do utilizador código e acesso à base de dados.

No tradicional arquitetura em camadasPor exemplo, as alterações numa camada podiam repercutir-se noutras camadas, levando a consequências indesejadas. Além disso, os testes eram complicados devido às complexas dependências entre camadas.

Arquitetura Hexagonal surgiu como uma solução, oferecendo um modelo em que as alterações numa parte do sistema não perturbariam as outras partes. Essencialmente, procurou tornar o lógica empresarial independente do facto de ser acedido através de uma interface Web, de um API REST, ou mesmo um linha de comando.

4. Componentes da arquitetura hexagonal

Arquitetura HexagonalO sistema de gestão de riscos, designado pela sua ilusão hexagonal nas representações esquemáticas, inclui três componentes principais: o modelo de domínioportas (primária e secundária) e adaptadores (primária e secundária).

O modelo de domínio é o coração da aplicação de software, encapsulando o regras de negócio e a lógica central. Os objectos de domínio que residem neste modelo contêm valores e regras comerciais específicos.

De seguida, temos as portas, condutas entre os modelo de domínio e o mundo exterior. Portos primários expõem o lógica empresarialOs utilizadores são os utilizadores que representam os casos de utilização que a aplicação suporta. Representam os casos de utilização que a aplicação suporta.

Portos secundáriospor outro lado, estão virados para o exterior. Representam interfaces que a aplicação requer do mundo exterior, como camadas de persistência ou serviços externos.

Por último, temos os adaptadores, que actuam como tradutores entre o modelo de domínio e o mundo exterior. Convertem dados do formato utilizado pelo sistemas externos para o formato utilizado pelo lógica empresariale vice-versa.

5. Portas e adaptadores

Portas e adaptadores formam a ponte entre o núcleo da aplicação e os actores externos. As portas primárias representam os casos de utilização comercial que a aplicação expõe, permitindo que os actores externos interajam com a aplicação. Pense nelas como as interfaces de serviço no seu camada empresarial.

As portas secundárias, por outro lado, são interfaces exigidas pela sua aplicação a partir do mundo exterior. Podem ser serviços como o acesso à base de dados, serviços webou mesmo serviços temporais. Expõem o que é necessário para a aplicação, independentemente de qualquer tecnologia ou caraterísticas específicas do fornecedor.

Os adaptadores são as manifestações físicas destas portas. Eles traduzem os dados do formato utilizado pelo lógica empresarial para o formato utilizado pelos actores externos e vice-versa. Esses adaptadores podem ser conversores de adaptadores específicos da tecnologia para APIs REST, bases de dados SQL ou sistemas de mensagens, mas também podem ser scripts em lote ou interface do utilizador código. Os adaptadores formam o limite da aplicação, permitindo que a aplicação seja independente da tecnologia.

6. Portas e adaptadores primários e secundários

As portas primárias representam as operações que a nossa aplicação pode efetuar - os comandos que o nosso domínio principal pode aceitar. Eles são frequentemente implementados como interfaces em linguagens como JavaA aplicação é um ficheiro que define as operações que a aplicação oferece.Adaptadores primáriossão, portanto, as implementações destas interfaces para actores externos específicos.

Por outro lado, as portas secundárias são interfaces que o domínio principal utiliza para interagir com o mundo exterior. Estas podem incluir interfaces para persistir objectos de domínio ou enviar notificações. Adaptadores secundários são as implementações efectivas destas interfaces - uma Base de dados SQL ou um adaptador de notificação por correio eletrónico, por exemplo.

Juntos, os portas e adaptadores primários e secundários formam um limite flexível e modular em torno da aplicação, separando o lógica de domínio de preocupações técnicas. Impõem uma separação clara de responsabilidades e permitem que diferentes partes do sistema evoluam de forma independente.

7. Regra de dependência e inversão de dependência

A regra da dependência é um princípio fundamental na Arquitetura Hexagonal que afirma que as dependências devem apontar para dentro, para o núcleo da aplicação. O núcleo da aplicação não depende de nenhuma base de dados, interface do utilizador ou qualquer outra agência externa em particular.

Este princípio está estreitamente ligado ao princípio Princípio da inversão de dependência (DIP), um dos princípios SOLID da conceção orientada para os objectos. O DIP estabelece que os módulos de alto nível (lógica empresarial ou camada de domínio não devem depender de módulos de baixo nível (como o adaptador de base de dados). Em vez disso, ambos devem depender de abstracções. Esta inversão de dependências permite que os módulos de alto nível sejam isolados das alterações nos módulos de baixo nível, promovendo uma conceção em que o lógica empresarial impulsiona a arquitetura global.

8. Mapeamento

O mapeamento é um processo essencial para Arquitetura Hexagonalem que um adaptador específico da tecnologia converte os dados do formato utilizado por sistemas externos para um formato que o nosso camada de domínio pode compreender. Este mapeamento facilita a tradução entre as representações internas e externas dos dados da aplicação.

Por exemplo, quando um pedido HTTP chega à nossa aplicação a partir de uma interface externa como um API RESTPara que os dados do pedido sejam traduzidos de JSON para objectos de domínio que a aplicação possa utilizar. Esta tradução é da responsabilidade dos adaptadores.

Por outro lado, quando a aplicação precisa de enviar uma resposta, os adaptadores convertem os objectos de domínio novamente em JSON. Isto permite que a aplicação central permaneça ignorante das especificidades do mundo externo, garantindo ao mesmo tempo que pode interpretar corretamente os dados de entrada e formatar os dados de saída.

9. Vantagens da arquitetura hexagonal

Arquitetura Hexagonal oferece uma grande variedade de benefícios, que podem ser atribuídos em grande parte à dissociação das aplicações de software dos seus elementos externos e à clara delimitação entre as diferentes partes de um sistema.

Um dos benefícios fundamentais é a separação de preocupações, promovendo a manutenção e a legibilidade do código. A dissociação do núcleo lógica empresarial do mundo exterior permite alterações em adaptadores específicos da tecnologia, bases de dados e interfaces de utilizador sem alterar o núcleo lógica empresarial.

Arquitetura Hexagonal também se destaca no domínio da testabilidade. O isolamento de dependências externas da arquitetura permite que os programadores executem testes de regressão automatizados e escrevam conjuntos de testes automatizados mais facilmente. Este isolamento aumenta a resiliência da aplicação, uma vez que as alterações num componente não terão um impacto negativo nos outros.

Além disso, a arquitetura suporta vários adaptadores para a mesma porta, abrindo a porta a vários adaptadores para a mesma porta secundária. Esta flexibilidade permite que a aplicação interaja com diferentes tipos de bases de dados ou suporte vários interface do utilizador plataformas.

10. Manutenção

No domínio do desenvolvimento de software, a capacidade de manutenção é muitas vezes uma caraterística procurada, mas que os estilos de arquitetura tradicionais podem ter dificuldade em oferecer. Arquitetura Hexagonal destaca-se aqui pela sua forte ênfase na facilidade de manutenção.

Ao centrar-se na separação das preocupações, Arquitetura Hexagonal garante que as alterações efectuadas numa parte da aplicação não se repercutem noutras partes. Esta caraterística ajuda a reduzir o tempo e o esforço despendidos na compreensão e depuração do código.

Além disso, a arquitetura incentiva a reutilização do código, promovendo uma conceção em que o núcleo lógica empresarial é isolado das tecnologias específicas utilizadas para conduzir a aplicação. Esta dissociação permite aos programadores trocar, atualizar ou refactorizar interfaces externas sem afetar a lógica central, reduzindo o risco de introdução de erros.

11. Redução da dívida técnica

A dívida técnica, uma preocupação significativa no desenvolvimento de software, refere-se ao custo futuro da refacção e da correção de atalhos e hacks no código. Arquitetura Hexagonal oferece uma abordagem proactiva para atenuar essa dívida.

Ao facilitar uma separação clara entre as actividades principais lógica empresarial e componentes externos, Arquitetura Hexagonal reduz a probabilidade de código entrelaçado que pode causar dores de cabeça na manutenção e agravar a dívida técnica. A capacidade de manutenção e de teste inerente à arquitetura também desempenha um papel na redução da dívida técnica, uma vez que ajuda a evitar a introdução de erros e facilita os esforços de refacção.

Além disso, a capacidade de Arquitetura Hexagonal para suportar alterações na infraestrutura sem necessidade de alterações na lógica empresarial fornece uma proteção contra dívidas técnicas. Esta capacidade permite às equipas adaptarem-se a alterações nos requisitos ou nas tecnologias sem terem de reescrever grandes partes da aplicação.

12. Arquitetura hexagonal na prática

Na prática, Arquitetura Hexagonal traz uma abordagem estruturada ao desenvolvimento de software. O limite hexagonal em torno da aplicação principal fornece uma demarcação clara de onde a aplicação termina e onde o mundo exterior começa.

Os adaptadores actuam como guardiões, traduzindo pedidos de actores externos para uma forma que a aplicação principal possa compreender, e vice-versa. Ao fazê-lo, garantem que a aplicação principal permanece agnóstica relativamente às especificidades do mundo exterior, quer se trate de uma base de dados, de um API externa, ou um interface do utilizador.

13. Conceção orientada para o domínio (DDD)

O Domain-Driven Design (DDD) é uma metodologia de desenvolvimento de software que dá prioridade aos conceitos fundamentais da atividade, ou seja, os lógica de domíniocomo a principal força motriz da conceção. Esta metodologia alinha-se muito bem com Arquitetura Hexagonalque sublinha igualmente a importância da lógica empresarial e o modelo de domínio na arquitetura.

No contexto de Arquitetura HexagonalO DDD garante que os módulos de alto nível da aplicação - as camadas de domínio - são independentes dos elementos externos, como o interface do utilizador ou a base de dados. Esta independência é assegurada pelos portos e adaptadores, que protegem a camada de domínio das especificidades do sistemas externos, permitindo assim que o lógica de domínio para evoluir de forma autónoma.

Além disso, Arquitetura Hexagonal complementa os princípios de conceção estratégica do DDD, incluindo o conceito de contextos delimitados. Cada contexto delimitado em DDD pode ser imaginado como um hexágono em Arquitetura Hexagonalcom o modelo de domínio no seu núcleo e o portas e adaptadores actuando como limites.

14. Microsserviços

Os microsserviços, outro estilo arquitetónico contemporâneo, podem beneficiar muito com Arquitetura Hexagonal. A natureza descentralizada dos microsserviços - em que cada serviço encapsula uma capacidade comercial específica - alinha-se perfeitamente com o encapsulamento de lógica empresarial dentro do núcleo do hexágono.

Tal como cada microsserviço deve ser fracamente acoplado a outros, cada hexágono em Arquitetura Hexagonal também está isolado dos outros, comunicando apenas através das portas e adaptadores definidos. Isto permite que cada microsserviço tenha o seu próprio arquitetura hexagonalresultando numa coleção de serviços autónomos e fracamente acoplados.

O isolamento proporcionado pela Arquitetura Hexagonal pode ser particularmente útil quando se lida com a complexidade e a natureza distribuída dos microsserviços. Ao isolar os lógica empresarial central do mundo exterior, Arquitetura Hexagonal garante a lógica empresarial permanece intacto, independentemente de alterações noutros serviços ou sistemas externos.

15. Comparação da arquitetura hexagonal com outras arquitecturas

A forma como o software é concebido pode ter um impacto profundo na sua evolução ao longo do tempo. Comparando Arquitetura Hexagonal para outras arquitecturas dá nós uma compreensão mais profunda dos seus pontos fortes e das suas potenciais soluções de compromisso.

16. Arquitetura hexagonal vs. arquitetura em camadas

Arquitetura em camadas é um produto tradicional padrão arquitetónico que estrutura uma aplicação em camadas lógicas - frequentemente camadas de apresentação, de negócio e de acesso aos dados. A principal desvantagem deste padrão é o facto de incentivar uma forte dependência entre as camadas, levando a uma situação em que as alterações numa camada podem repercutir-se em toda a aplicação.

Em contrapartida, Arquitetura Hexagonal minimiza essas dependências. Em vez de camadas, tem um núcleo da aplicação rodeado de adaptadores intermutáveis. As alterações num servidor de bases de dados, por exemplo, só afectariam o adaptador correspondente, deixando o núcleo da aplicação e outros adaptadores intactos.

17. Arquitetura Hexagonal vs. Arquitetura Limpa

Arquitetura limpa, outro padrão arquitetónicopartilha muitas semelhanças com Arquitetura Hexagonal. Ambos enfatizam a separação de preocupações, têm como objetivo isolar o núcleo regras de negócio de pormenores externos, e aderir ao Princípio da inversão de dependência.

No entanto, Arquitetura Hexagonal centra-se mais na forma como a aplicação interage com o no exterior mundo utilizando portas e adaptadores, enquanto Arquitetura limpa fornece uma estrutura mais detalhada para as camadas internas da arquitetura. Por outras palavras, Arquitetura limpa pode ser visto como um superconjunto de Arquitetura Hexagonalcom orientações adicionais sobre a organização da estrutura interna da aplicação.

18. Arquitetura Hexagonal vs. Arquitetura Onion

Arquitetura da cebola é outro estilo arquitetónico que visa isolar o lógica empresarial central do interfaces externas e infra-estruturas. Tem vários níveis concêntricos, com o modelo de domínio no centro, e cada nível só pode depender dos níveis que lhe estão associados.

Embora partilhem um objetivo comum, a Hexagonal e a Arquitetura da cebola conseguem-no de formas ligeiramente diferentes. Arquitetura da cebola coloca muita ênfase na direção das dependências, assegurando que todas as dependências vão para dentro. Arquitetura Hexagonalembora também apoie as dependências viradas para o interior, coloca uma maior ênfase na interação com o mundo exterior através das suas portas e adaptadores.

19. Ensaios em arquitetura hexagonal

Um dos principais pontos fortes da Arquitetura Hexagonal é o seu foco na testabilidade. Ao isolar a aplicação principal da mundo exterior através de portas e adaptadores, a Arquitetura Hexagonal permite a execução de testes automatizados que pode proporcionar confiança na estabilidade e correção do software.

Num Arquitetura Hexagonal, o portos primáriosque encapsulam o núcleo regras de negócioO teste de uma base de dados real pode ser efectuado independentemente do mundo exterior. Por exemplo, em vez de comunicar com uma base de dados real durante o teste, um adaptador de base de dados pode ser trocado por um teste duplo que simula o comportamento de uma base de dados real. Isto permite que os programadores se concentrem em testar o regras de negócioem vez da interação com a base de dados.

Além disso, testes de regressão automatizados podem ser facilmente construídos para validar que o sistema se comporta como esperado quando são feitas alterações. Este nível de testabilidade é uma vantagem significativa quando se trata de manter e atualizar software, uma vez que ajuda a detetar e corrigir problemas numa fase inicial do processo. processo de desenvolvimento.

Além disso, a estrutura de Arquitetura Hexagonal também suporta testes de integração. Ao substituir o componentes externos (como um servidor de base de dados ou um API externa) com duplos de teste, os programadores podem testar como o núcleo da aplicação integra-se com estes componentes sem ter de utilizar os sistemas externos actuais. Isto pode melhorar significativamente a velocidade e a fiabilidade dos testes.

Conclusão

Arquitetura Hexagonal surge como uma solução aliciante no vasto leque de estratégias de desenvolvimento de software. Distingue-se pelo facto de dissociar o núcleo da aplicação do ambiente externo, garantindo assim um elevado grau de manutenção, testabilidade e flexibilidade. Esta separação facilita aos programadores a concentração no núcleo lógica empresariale, simultaneamente, reforçar a capacidade de resistência do software face a alterações na sistemas externos.

Embora existam compensações associadas à Arquitetura Hexagonal, a sua multiplicidade de benefícios torna-a um ativo altamente valioso para a caixa de ferramentas de qualquer programador. No domínio da arquitetura de softwareO modelo hexagonal continua a afirmar o seu domínio.

Este artigo, salpicado de exemplos de códigotem por objetivo proporcionar uma compreensão aprofundada de Arquitetura Hexagonal e os seus potenciais benefícios. Não se esqueça de que o segredo de uma arquitetura eficaz não reside na adesão cega a padrões, mas sim na compreensão dos princípios subjacentes e na sua implementação ponderada para satisfazer requisitos específicos.

No domínio da Arquitetura Hexagonal, a interface definida entre os camada de aplicação e o camada de dados é de extrema importância. Quer se trate de um arquiteto de software Seja para quem considera adotar esta metodologia, seja para um programador que se esforça por compreender as suas complexidades, é evidente que a influência desta arquitetura continua a crescer. Ela demonstra várias maneiras de ser utilizada de forma eficaz. Por exemplo, em um bancário aplicação, o interface do repositório pode atuar como um adaptador secundário, fazendo a ponte entre o núcleo da aplicação com código externo. Esta separação permite a flexibilidade de trocar o aplicação concreta de um sistema de ficheiros ou uma tecnologia específica, sem afetar os serviços de aplicação.

O desenvolvimento equipa pode agora trabalhar no lado esquerdo da aplicação sem se preocupar com factores externosgarantindo assim um progresso sem falhas. E assim, concluímos a nossa exploração do mundo do Arquitetura Hexagonalum estilo arquitetónico que continua a estender a sua influência ao panorama do desenvolvimento de software.
faixa de cooperação

Artigos relacionados

Desenvolvimento de software

PHP 8.2: O que há de novo?

A nova versão do PHP está quase a chegar. Quais são as novas implementações que deve conhecer? Consulte este artigo para ficar a saber!

The Codest
Sebastian Luczak PHP Chefe de unidade
Desenvolvimento de software

Prós e contras do Python

Durante mais de 30 anos, o python foi utilizado por muitos programadores de software em todo o mundo. Mesmo em 2022, as pessoas ainda estão a aprender esta linguagem de programação altamente versátil...

The Codest
Tomasz Szkaradek Arquiteto de desenvolvimento
Soluções para empresas e escalas

Trabalhar de forma mais inteligente, não mais difícil: Como os desenvolvedores adicionais podem acelerar o Project Development

No atual panorama empresarial de ritmo acelerado e em constante evolução, trabalhar de forma mais inteligente, e não mais difícil, é essencial para o sucesso. Isto é particularmente verdade no sector das TI, onde a procura de soluções inovadoras e...

The Codest
Greg Polec CEO
E-commerce

Onde é melhor usar o Node.js

Descubra o desenvolvimento do Node.js, conheça os serviços oferecidos pelas agências e saiba como escolher uma para o sucesso do seu projeto.

thecodest

Subscreva a nossa base de conhecimentos e mantenha-se atualizado sobre os conhecimentos do sector das TI.

    Sobre nós

    The Codest - Empresa internacional de desenvolvimento de software com centros tecnológicos na Polónia.

    Reino Unido - Sede

    • Office 303B, 182-184 High Street North E6 2JA
      Londres, Inglaterra

    Polónia - Pólos tecnológicos locais

    • Parque de escritórios Fabryczna, Aleja
      Pokoju 18, 31-564 Cracóvia
    • Embaixada do Cérebro, Konstruktorska
      11, 02-673 Varsóvia, Polónia

      The Codest

    • Início
    • Sobre nós
    • Serviços
    • Case Studies
    • Saber como
    • Carreiras
    • Dicionário

      Serviços

    • Aconselhamento
    • Desenvolvimento de software
    • Desenvolvimento backend
    • Desenvolvimento de front-end
    • Staff Augmentation
    • Programadores de back-end
    • Engenheiros de nuvem
    • Engenheiros de dados
    • Outros
    • Engenheiros de GQ

      Recursos

    • Factos e mitos sobre a cooperação com um parceiro externo de desenvolvimento de software
    • Dos EUA para a Europa: Porque é que as empresas americanas decidem mudar-se para a Europa?
    • Comparação dos centros de desenvolvimento da Tech Offshore: Tech Offshore Europa (Polónia), ASEAN (Filipinas), Eurásia (Turquia)
    • Quais são os principais desafios dos CTOs e dos CIOs?
    • The Codest
    • The Codest
    • The Codest
    • Privacy policy
    • Website terms of use

    Direitos de autor © 2026 por The Codest. Todos os direitos reservados.

    pt_PTPortuguese
    en_USEnglish de_DEGerman sv_SESwedish da_DKDanish nb_NONorwegian fiFinnish fr_FRFrench pl_PLPolish arArabic it_ITItalian jaJapanese es_ESSpanish nl_NLDutch etEstonian elGreek cs_CZCzech pt_PTPortuguese