Clean Architecture
Tags: braziliandevs, todayilearned, beginners
Published: 2022-05-26 02:00:41

## 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
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/56c6k1wybrsiz18jvyge.png)
 
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.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/d8c47f6dhu9snyvw9c69.png)

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.

```js
  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