Categoria: software design

O que é arquitetura hexagonal

Tiago Temporin3 Comentários

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 »

Aplicando Liskov Substitution Principle

Tiago TemporinDeixe um comentário

Dando início ao quarto post da série sobre SOLID, vamos falar um pouco sobre Liskov Substitution Principle.

Se você ainda não leu os outro posts da série, vou deixar os links aqui para que o faça.

Liskov Substitution, dos cinco princípios do SOLID, talvez seja o mais simples para se aplicar. Vamos relembrar o que diz esse princípio.

Classes “filhas” podem ser utilizadas no lugar das classes “pais” sem que o programa quebre. Em outras palavras, uma classe filha, mesmo com suas especificidades, deve manter o mesmo comportamento da classe pai.

Aqui, antes de continuar, vale fazer duas observações.

  1. Não existe orientação a objetos em Go, logo não temos classes.
  2. Como não temos classes, não temos herança.

Nesse momento você deve estar se perguntando. Se não temos classes e nem herança, como podemos aplicar esse princípio no Go?

Simples! Onde o princípio diz classe, pense em structs. Já onde diz herança, pense na técnica de embedding.

Ok! Agora que estamos alinhados, voltemos ao princípio.

Leia mais »
gray and brown concrete brick wall

O que é SOLID?

Tiago Temporin5 Comentários

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 »