O que são entidades?

Chamadas de enterprise Business Rules -> Entidades. São o inicio do desenvolvimento e é a camada central que engloba as regras cruciais de negócios, ou seja, são objetos que organizam essas regras permitindo que a gente acesse e processe essas informações.
São identificáveis por uma informação única dentro de nosso sistema (id)
É diferente de um padrão de entidade criado em ORMs, pois possuem expressividades dentro da aplicação pois possuem regras de negocios e são agnosticas a frameworks e a linguagens de programação.
Possuem regras de negócios mais puristas.
É considerado o coração da aplicação, pois provê os recursos sobre os a regra da aplicação é regida.

O que são useCases? (caso de uso)

Centralizam regras de negócios de acordo com a necessidade da aplicação como apontar operações que podem envolver banco de dados, ou realizar publicação em serviços de mensagerias, por exemplo...
Se integram com as regras construídas na entidade da aplicação.

Controllers

Acesssam os casos de uso

O que são domain experts? (Especialista de dominio)

São pessoas que contém o conhecimento da regra de negócio, ou seja, são pessoas que detem o conhecimento de como a aplicação deve funcionar de acordo com seu dia a dia de trabalho. Ex: Em um setor administrativo temos rotinas, passo a passo relacionado gestão e arquivamento de documentos.

Observações

As alterações em camadas mais externas não devem interferir nas camadas mais internas.
As camadas precisam do que chamamos de limites arquiteturais.
- Ou seja, a camada de Entidade nunca deverá ser alterada
- A camada de useCase tende a mudar muito pouco relacionado as camadas mais externas.
Linguagem Ubiqua -> é uma linguagem descritiva sobre as representações repassadas pelo domain expect
Livre-se do FDD (Desenvolvimento orientado a framework)
Expressividade é o mesmo que regra de negocios
Padrão de pastas @seedwork representa uma pasta onde são criados objetos de valores, ou seja recursos que podem ser compartilhados entre os outros modulos da aplicação em uma especie de shared. A nomenclatura "@" diz que essa pasta sempre aparecerá na primeira posição no ordenamento de pastas.
Objeto de valor nao possui identidade própria.

Informações do diagrama de caso de uso:

Admin:
- Criar categoria
- Atualizar categoria
- Excluir categoria
- Consultar uma categoria
- Consultar categorias

Diagrama de classe - Montagem da Entidade

Entity Category
- Category: id uuid
- name string
- description string
- is_active boolean
- created_at date
Category : Create()
Category : Update()
Category : Activate()
Category : Deactivate()
Category : delete()

Obs:

trabalhar com sets em excesso pode tirar a expressividade da entidade tornando-a anemica.
é importante pensar nas operações de forma agnostica a qualquer recurso externo. Uma boa arquitetura permite adiar decisões.
Quando se constroi uma entidade com esses conceitos de arquitetura as props da entidade nem sempre serão obrigatórias. Ex: Imagine que na nossa entidade com name, description, is_active, created_at, description seja facultativo... obrigatóriamente todas as props seguintes tambem precisam ser facultativas, pois dentro de metodos e construtores não é possível que uma prop da metade do ordenamento seja opcional. Props opcionais devem ficar por ultimo nas suas declarações.
Com isso utilizamos interfaces que permitem flexibilizar esse manuzeio

Clean Architecture: Criado por Uncle Bob Robert C Martin em 2012

Ponto focal de arquitetura limpa, consiste em

Proteger o núcleo central e dominios da aplicação
Cria contratos (intefaces) entre as camadas
Baixo acoplamento entre as camadas
Orientada a casos de uso (são intensões do usuario para com o sistema)
Percepção sobre regras de negócios

Key Option Open

Criar limites arquiteturais muito claros acaba por criar partes que não dependam diretamente uma da outr além de nos permitir postergar decisões.

Pontos importantes sobre arquitetura:

Formato que o Software terá - Ligado ao design de software
Divisão de componentes - Pensar a nível de arquitetura quais componentes ele terá
Comunicação entre esses componentes
Uma boa arquitetura vai facilitar o processo de desenvolvimento, deploy, operação e manutenção.

Regras vs Detalhes

Regras de negocio trazem o real valor para o sistema
Detalhes ajudam a suportar as regras
Detalhes não devem imapctar nas regras de negócio
Frameworks, banco de dados, apis, não devem imapactar as regras
O Core da sua aplicação é o mais importante

DDD - Atacar a complexidade no coração do software

A importancia de casos de uso (UseCases)

Representam uma intenção - Cada ação é uma intenção e cada intenção e um caso de uso
Clareza de cada comportamento do software
Detalhes não devem impactar nas regras de negocio
Frameworks, banco de dados, apis não devem impactar nas regras de negócios

UseCases - SRP (Single responsability Principle)

Temos a tendencia de "reaproveitar" use cases por serem muito parecidos.
Ex: Alterar vs Inserir. Ambos consultam se o registro existe, persistem dados. MAS, são useCases diferentes. Porque?
SRP - Mudam por razões diferentes Quando a alteração naquele código é diferente, muda quando voce faz alterações por razões diferentes significa que o SRP está sendo ferido, cada use cases apesar de parecido tem razões de mudanças diferentes.

Duplicação real vs Duplicação acidental

Falsas duplicações nos faz perceber que conforme o sistema vai mudando suas etapas de codigo andam por caminhos diferentes

Use Cases contam historias

Muitas vezes uma intenção pode soar muito estranho
use case é a concretização de uma automatização, visto que um sistema é automatização de tarefas
O use case é o orquestrador do fluxo dentro da aplicação Ex: Simulação de caso de uso (Emprestimo)- regra de negocio que é chamada a partir do use case 1 - Aceita e valida o nome 2 - Valida endereço, aniversário, DL, SSN... 3 - Capta o credit score 4 - Valida se o credit score é < 500, se não ela nega 5 - Se não ele cria a estimativa de emprestimo.

Limites arquiteturais:

Divisão de componentes e estabilização de contratos Tudo que nao impacta diretamente nas regras de negocio deve estar em um limite arquitetural diferente. Ex: Não será o Frontend, banco de dados que mudarão as regras da aplicação.

A camanda de negócios inversamente chama a camada de regras de negócios Nunca a camada de regras de negocios deve chamar a camada que acessa banco de dados

Input vs Output

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 raciocinio ao criar um software sempre pensando em Input e Output
Inputs geralmente vem de qualquer lugar, porém no fim do dia sempre vai ser um input, da mesma forma ocorre com o Output

DTO - (Data Transfer Objct)

Trafegar os dados entre os limites arquiteturais Ex: Trafega os dados entre as camadas criando um Objeto que é utilizado para trafegar esses dados
Objeto anemico, não possui comportamento livre de regras
Contem dados (Inputs e Outputs) =====> Controller =====> useCase useCase ======> Controller
Outro ponto importante é que cada intensão do sistema muitas vezes precisa de DTOs diferentes Ex: Imagine que queremos criar uma categoria, criamos um DTO onde precisamos ter um Objeto com Atributos que retorne esse fluxo
Para alterar dados devemos criar um novo DTO que vai tratar os dados especificos para alteração
São diferentes pois cada DTO segue um caminho diferente

Ex: DTO input - Request

API -> CONTROLLER -> USE CASE -> ENTITY O fluxo de devolução da informação também funciona via DTO
Controller cria um DTO com os dados recebidos, cria um DTO para output e retorna para o controller

Presenters

Objetos de transformação
Adequa o DTO de output no formato correto para entregar o resultado
Lembrando: Um sistema por ter diversos formatos de entrega, ex: XML, JSON, Protobuf, GraphQL, CLI... Ex: Criação de um DTO que será trafegado input = new CategoryInputDTO("name"); output = CreateCategoryUseCase(input); -> A partir daqui estamos trafegando dados de uma camada para outra jsonResult = CategoryPresenter(output).toJson(); -> Convertemos o output para um JSON, mas poderia ser qualquer coisa

Entidades - Entities

Entities da Clean Architecture !== Entities do DDD
No DDD são Camadas de agregado, no Clean Arch é um conceito de camada com regras de negocios
Elas se aplicam em qualquer situação pois são o core da aplicação com regras de negocios globais
Não há definição explicita de como criar as entities
Normalmente utilzamos táticas do DDD
Entities = Agregados + Domain Services
useCase pode varia com o fluxo / entity tem suas regra solidificadas