O Curso GO Expert é uma formação completa para fazer com que pessoas desenvolvedoras sejam capazes de trabalhar em projetos expressivos sendo capazes de desenvolver aplicações de grande porte utilizando de boas práticas de desenvolvimento.
https://github.com/alcir-junior-caju/study-go-expert
Para quem quiser visualizar o projeto na IDE clique no teclado a tecla ponto
, esse recurso do GitHub é bem bacana
O projeto utiliza Dcoker
então é necessário o Docker
e Docker Compose
instalado em sua máquina.
Para iniciar o projeto siga os passos:
- Na raiz do projeto execute o comando
docker compose up --build
e aguarde oscontainers
domysql
erabbitmq
iniciarem; - Para acessar o
rabbitmq
acesse:http://localhost:15672
comguest
parausername / password
; - Adicione a fila clicando em
Queues and Streams
no camponame
coloqueorders
e clique emAdd queue
; - Criada a fila acesse ela e em
Bindings
no campoFrom exchange
coloqueamq.direct
; - Para rodar as
migrations
é necessário ter instalado aCLI
dogolang-migrate
siga essa documentação: https://github.com/golang-migrate/migrate/tree/master/cmd/migrate; - Com a
CLI
instalada na raiz do projeto execute o comandomake migrateup
para criar a tabela emake migratedown
para excluir a tabela; - Entre o diretório
cmd/ordersystem
e execute o comandogo run main.go wire_gen.go
;
Com isso o sistema já está pronto para o uso, para testar existe algumas formas:
REST API
:- No diretório
api
tem um arquivocreate_order.http
que usa umplugin
dovscode
declient rest
https://github.com/Huachao/vscode-restclient basta executar asrequests
por esse arquivo.
- No diretório
GRPC
:- Para utilizar o
GRPC
é necessário umclient
, o que foi utilizado nesse projeto é esse: https://github.com/ktr0731/evans mas pode consumir com algum outro caso queira, para utilizar oEvans
execute o comandoevans -r repl
digitecall
e ao dar um espaço já irá aparecer os serviços diponíveis,CreateOrder
cria um novo registro eListOrder
lista as ordens;
- Para utilizar o
GraphQL
:- Para utilizar
GraphQL
acessehttp://localhost:8080/
e cria amutation
para inserir dados:
mutation createOrder { createOrder(input: { id: "abc", Price: 12.2, Tax: 2.0 }) { id Price Tax FinalPrice } } query queryOrders { orders { id Price Tax FinalPrice } }
- Para utilizar
- Termo criado por Robert C. Martin (Uncle Bob) em 2012;
- Trouno-se um livro;
- Buzz word;
- Proteção do domínio da applicação;
- Baixo acoplamento entre as camadas;
- Orientada a casos de uso;
- Ele fala especificamente sobre Clean Architecture em 7 páginas do livro;
- Tudo que ele fala especificamente sobre Clean Architecture está literalmente em um artigo em seu blog;
- Reforçar conhecimento e remover gaps básicos que muitas vezes nem percebemos ter;
- Componentes;
- Arquitetura;
- Limites arquiteturais;
- Percepção sobre regras de negócios;
- Formato que o software terá;
- Divisão de componentes;
- Comunicação entre componentes;
- Uma boa arquitetura vai facilitar o processo de desenvolvimento, deploy, operação e manutenção;
- O objetivo principal da arquitetura é dar suporte ao ciclo de vida do sistema. Uma boa arquitetura torna o sistema fácil de entender, fácil de desenvolver, fácil de manter e fácil de implantar. O objetivo final é minimizar o custo de vida útil do sistema e maximizar a produtividade do programador;
- Regras de negócio trazem o real valor para o software;
- Detalhes ajudam a suportar as regras;
- Detalhes não devem impactar nas regras de negócio;
- Frameworks, banco de dados, apis, não devem impactar as regras;
- DDD - Atacar a complexidade no coração do software;
- Intenção;
- Clareza de cada comportamento do software;
- Detalhes não devem impactar nas regras de negócio;
- Frameworks, banco de dados, apis, não devem impactar as regras;
- Temos a tendência de reaproveitar user cases por serem muito parecidos;
- Ex.: Alterar x Inserir. Ambos consultam se o registro existe, persistem dados, Mas, são Use Cases diferentes. Por que?
- SRP (Single Responsibility Principle) mudam por razões diferentes;
- Duplicação real x Acidental;
- Tudo que não impacta diretamente nas regras de negócio deve estar em um limite arquitetural diferente. Ex.: Não será o frontend, banco de dados que mudarão as regras de negócio da aplicação.
- No final do dia, tudo se resume a um input que retorna um output;
- Ex.: Criar um pedido (dados do pedido = input), Pedido criado(dados de retorno do pedido);
- Simplifique seu racicocínio ao criar um software sempre pesando em Input e Output;
- Trafegar dados entre os limites arquiteturais;
- Objeto anêmico, sem comportamento;
- Contém dados (Input ou Output);
- Não possuí regras de negócio;
- Não possuí comportamento;
- Não faz nada;
- API -> Controller -> Use Case -> Entity;
- Controller cria um DTO com os dados recebidos e envia para o Use Case;
- Use Case executa seu fluxo, pega o resultado, cria um DTO para output e retorna para o Controller;
- Objetos de transformação;
- Adequa o DTO de Input no formato correto para entregar o resultado;
- Lembrando: Um sistema por ter diversos formatos de entrega: Ex.: ZML, JSON, Protobuf, GraphQL, CLI, etc;
- input = new CategoryInputDTO('name');
- output = CreateCategoryUseCase(input);
- jsonResult = CategoryPresenter(output).toJson();
- xmlResult = CategoryPresenter(output).toXML();
- Entities da Clean Architecture <> Entities do DDD;
- Clean Architecture define Entity como camada de regras de negócio;
- Elas se aplicam em qualquer situação;
- Não há definição explicita de como criar as Entities;
- Normalmente utilizamos táticas do DDD;
- Enities = Agregados + Domain Services;