Curso Full Cycle 3.0 - Módulo Clean Architecture

Descrição

O Curso Full Cycle é 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.

Repositório Pai

https://github.com/alcir-junior-caju/study-full-cycle-3-0

Visualizar o projeto na IDE:

Para quem quiser visualizar o projeto na IDE clique no teclado a tecla ponto, esse recurso do GitHub é bem bacana

Clean Architecture

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;

Curiosidades sobre o livro

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;

Porque ler o livro

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;

Pontos importantes sobre arquitetura

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;

Objetivos de uma boa arquitetura

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;

Rgras x Detalhes

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;

Use Cases

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;

Use Cases - SRP

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;

Limites arquiteturais

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.

Input x Output

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;

DTO - Data Transfer Object

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;

Presenters

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

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;

alcir-junior-caju/study-full-cycle-3-0-clean-architecture