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
- Aceitar e validar o nome
- Validar o endereço, etc.
- Pegar o score de credito.
- Se o score de credito for menor que 500 recusar.
- 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
Oldest comments (1)
legal