Clean Architecture

Origem

Foi um termo criado pelo Robert C. Martin no seu prprio blog e depois ele adaptou para um livro assim como a arquitetura hexagonal a clean architecture visa a proteo do domnio da aplicao e o baixo acoplamento entre as camadas.

Pontos importantes sobre arquitetura

• Define o formato que o software ter
• Responsvel 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 fcil de manter, melhorar, entender e fazer o deploy.

Use Cases

Casos de uso representa, uma inteno de uma ao que o software realiza. Cada comportamento deve ser claro. Detalhes no devem impactar nas regras de negcio. Frameworks, bancos de dados e apis no devem impactar nas regras de negcio.

Cada use case deve seguir o principio da responsabilidade nica.
Ex: Alterar e inserir um produto so semelhantes, ambos realizam uma consulta no banco de dados e fazem uma persistncia. porem so useCases diferentes. Ou seja sempre que a inteno da alterao diferente deve ser um useCase diferente

Use cases contam uma historia

Na imagem um exemplo do fluxo de juntar as informaes de contato para gerar um novo emprstimo. enumerado uma lista de passos que a aplicao deve seguir para esse use case

1. Aceitar e validar o nome
2. Validar o endereo, 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 emprstimo

Limites arquiteturais

Tudo que no impacta diretamente nas regras de negcio deve estar em um limite arquitetural diferente.
Ex: no ser o frontend, banco de dados que mudar as regras de negocio da aplicao.

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 negcios no 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 raciocnio ao criar um software pensando dessa forma. O DTO contem os dados ou do input ou do output

Ele responsvel por pegar esses dados e transportar pelos limites arquiteturais. Alm disso o DTO um objeto anmico, ele no possui regras, apenas possui dados.

Geralmente cada inteno dos sistema precisa de DTOS diferentes, por exemplo criar um produto e fazer update no produto precisam de campos diferentes, no mnimo o update precisa de 1 campo a mais (o ID)

Presenters

Objetos de transformao, a funo 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 so diferentes do DDD. Na clean architecture as entidades so definidas como uma camada enquanto no DDD a representao de algo nico na aplicao.

Como a clean architecture define entidade como uma camada da regra de negocio elas se aplicam em qualquer situao.

No existe uma definio explicita de como criar as entidades porem normalmente utilizado as tticas 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 domnio inteiro