Origem

Foi um termo criado pelo Robert C. Martin no seu próprio blog e depois ele adaptou para um livro assim como a arquitetura hexagonal a clean architecture visa a proteção do domínio da aplicação e o baixo acoplamento entre as camadas.

Pontos importantes sobre arquitetura

• Define o formato que o software terá
• Responsável por dividir os componentes de forma clara
• Os componentes precisam ter formas de se comunicar um com o outro
• Uma boa arquitetura deve ajudar a tornar um sistema fácil de manter, melhorar, entender e fazer o deploy.

Use Cases

Casos de uso representa, uma intenção de uma ação que o software realiza. Cada comportamento deve ser claro. Detalhes não devem impactar nas regras de negócio. Frameworks, bancos de dados e apis não devem impactar nas regras de negócio.

Cada use case deve seguir o principio da responsabilidade única.
Ex: Alterar e inserir um produto são semelhantes, ambos realizam uma consulta no banco de dados e fazem uma persistência. porem são useCases diferentes. Ou seja sempre que a intenção da alteração é diferente deve ser um useCase diferente

Use cases contam uma historia

Na imagem um exemplo do fluxo de juntar as informações de contato para gerar um novo empréstimo. É enumerado uma lista de passos que a aplicação deve seguir para esse use case

1. Aceitar e validar o nome
2. Validar o endereço, etc.
3. Pegar o score de credito.
4. Se o score de credito for menor que 500 recusar.
5. Criar o cliente e ativar a estimativa de empréstimo

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á as regras de negocio da aplicação.

As regras de negocio chamam uma interface para se comunicar com o banco de dados, e o database access implementa esse banco de dados, fazendo que as regras de negócios não precisem saber nada sobre o banco de dados, somente sobre a interface

DTO (Data Transfer Object)

No final das contas tudo é input e output. Dessa forma podemos simplificar nosso raciocínio ao criar um software pensando dessa forma. O DTO contem os dados ou do input ou do output

Ele é responsável por pegar esses dados e transportar pelos limites arquiteturais. Além disso o DTO é um objeto anêmico, ele não possui regras, apenas possui dados.

Geralmente cada intenção dos sistema precisa de DTOS diferentes, por exemplo criar um produto e fazer update no produto precisam de campos diferentes, no mínimo o update precisa de 1 campo a mais (o ID)

Presenters

Objetos de transformação, a função deles é adequar um DTO que lhe foi inputado para um formato correto de entregar um resultado, Ex.: JSON, Protobuf, GraphQl, CLI, etc.

  input = new CategoryInputDto("name")
  output = CreateCategoryUseCase(input);
  jsonResult = CategoryPresenter(output).toJson();

Nesse exemplo passamos o DTO de input e recebemos um dto de output, e ai usamos o presenter para transformar esse dto de output em um objeto json e retornar para o usuario

Entities

Entidades na clean architecture são diferentes do DDD. Na clean architecture as entidades são definidas como uma camada enquanto no DDD é a representação de algo único na aplicação.

Como a clean architecture define entidade como uma camada da regra de negocio elas se aplicam em qualquer situação.

Não existe uma definição explicita de como criar as entidades porem normalmente é utilizado as táticas do DDD, podemos partir do principio que a entidade na clean arch é a soma dos agregados com os domain services do DDD, tratando assim uma entidade como um domínio inteiro