O que é arquitetura hexagonal

Nesse primeiro post sobre arquitetura de software, vamos falar um pouco sobre a arquitetura hexagonal. Proposta em 2005 por Alistair Cockburn, a arquitetura hexagonal visa um projeto com:

  • Separação de responsabilidades: cada componente tem sua responsabilidade bem definida.
  • Foco na regra de negócio: a separação de camadas e componentes, proporciona um melhor detalhamento e foco na regra de negócio da aplicação.
  • Paralelização de trabalho: como a arquitetura hexagonal define muito bem as responsabilidades de cada componente, é possível paralelizar trabalho facilmente.
  • Isolamento de testes: devido a baixa dependência entre componente, escrever testes de qualidade, se torna uma tarefa muito mais simples.
  • Mudança de infraestrutura: como existe uma separação entre a regra de negócio e a camada que se comunica com o mundo exterior, mudar do MySQL para Postgres é menos doloroso do que em aplicações que não seguem a arquitetura hexagonal.

Em outras palavras, utilizar a arquitetura hexagonal faz com que um projeto seja escalável, de fácil manutenção e produtivo na hora de ser implementado.

Agora vamos entender os termos e camadas da arquitetura hexagonal.

Leia mais »

O que é e como aplicar Dependency Inversion Principle

Nesse segundo post da série de posts sobre SOLID em Go, foquemos na letra ‘D’, ou seja, no Dependency Inversion Principle.

Se você não viu o primeiro post da série, recomendo a leitura para ter uma visão geral do que é SOLID.

Antes de ver como aplicar Dependency Inversion Principle em Go, vamos relembrar seu conceito.

Dependências devem ser abstraídas, para que os módulos de alto nível não dependam dos módulos de baixo nível.

Para facilitar o entendimento, vejamos um pouco de código. Para começar, um exemplo de como violar o Dependency Inversion Principle.

Leia mais »
gray and brown concrete brick wall

O que é SOLID?

SOLID é um acrônimo que representa cinco princípios no design de softwares orientados a objetos, sendo:

Single Responsability
Open-Closed
Liskov Substitution
Interface Segregation
Dependency Inversion Principle

Embora Go não seja uma linguagem orientada a objetos, ainda assim conseguimos utilizar os princípios de SOLID. Abaixo, vamos ver com mais detalhes cada um dos princípios.

Single Responsability

Uma classe ou, como é no caso do Go, uma struct deve ter uma única responsabilidade. Ou seja, cada struct deve ser projetada para executar uma determinada ação.

Pensando em um CRUD, é claro que você não terá uma struct para cada uma das ações (Create, Read, Update e Delete). Mas também não terá somente uma struct para lidar com todas as responsabilidades do package.

O ideal é ter pelo menos uma struct que represente a entidade do package. Uma para lidar com as transações com banco de dados, comumente chamada de repository. E outra para tratar as requests, independente se forem via API ou em algum modelo MVC.

Leia mais »
crop nurse with syringe ready to vaccinate patients

O que é e como utilizar Dependency Injection

Se você já ouviu falar mas não sabe ao certo o que é Dependency Injection ou como a utilizar em Golang, nesse post espero te ajudar a sanar as duas dúvidas.

Para que todos estejam na mesma página, antes de ver como utilizar, vamos falar um pouco sobre o que é essa tal Dependency Injection ou DI para os íntimos.

Podemos definir DI (Dependency Injection) como uma técnica onde os módulos recebem todas ou parte de suas dependências de forma indireta, ou seja, por parâmetro em uma função/método ou sendo passada diretamente para o campo de uma struct, onde tais parâmetros ou campos não tenham um tipo definido, mas sim uma interface.

Vantagens da Dependency Injection

Utilizar essa técnica ajuda com que nosso código tenha baixo acoplamento, o que torna a tarefa de refatorar partes do sistema muito mais fácil.

Leia mais »