Clean Architecture com ASP.NET Core – Parte #4

Aprenda a como implementar o Clean Architecture (ou Arquitetura Limpa) com ASP.NET Core nessa série de artigos.

Nesta parte #4 irei falar sobre a camada Application, explicando seus objetivos e descrevendo seus componentes.

Código-fonte aqui.


Quer ser notificado sobre os próximos artigos, lives semanais, eventos e treinamentos? Entre no canal LuisDev no Telegram!


A camada Application

A camada Application é constituída pelos seguintes componentes:

  • Modelos de Entrada
  • Modelos de Saída
  • Serviços de Aplicação (depende do padrão adotado)
  • Commands e Queries (depende do padrão adotado)

Vou detalhar mais sobre esses componentes, construindo o sistema de exemplo proposto na parte #1, que é de um gerenciador de academia.


Modelos de Entrada

Também conhecidos como Input Models, ou mesmo DTOs (que seria um termo mais genérico a objetos que transferem dados), os modelos de entrada são classes que representam informações do mundo exterior na API. Devem conter apenas as informações essenciais para a operação da aplicação, e são geralmente mapeados para entidades do domínio em operações como cadastro e atualização.

Um exemplo do projeto é a UnidadeInputModel, que representa os dados necessários para se cadastrar uma Unidade.

Modelo de entrada para cadastro de Unidade

Modelos de Saída

Também conhecidos como View Models, ou DTOs, os modelos de saída são classes que representam informações que “saem” da aplicação para o cliente (seja uma aplicação Front-End, ou outra aplicação Back-End). Geralmente são utilizados em consultas.

Um exemplo do projeto é o UnidadeItemViewModel, que é utilizado na listagem de Unidades.

Modelo de saída de consulta de Unidades

Serviços de Aplicação

São as classes responsáveis por coordenar a lógica de aplicação, realizando chamadas a métodos de Repositórios, classes de domínio, serviços de Infraestrutura, entre outros.

Seus métodos representam ações diretas no sistema, geralmente recebendo modelos de entrada (Input Models), e retornando modelos de saída (View Models). Além disso, é comum ter um Serviço de Aplicação para cada entidade/Controller.

Por acumular funcionalidades relacionadas à mesma entidade em uma mesma classe, um Serviço de Aplicação pode crescer de maneira considerável. Algumas alternativas para evitar isso é dividir métodos do Serviço de Aplicação em classes de escrita e leitura, ou mesmo utilizar outro padrão como o CQRS.

Um exemplo de serviço criado é o UnidadeService, que implementa a interface IUnidadeService. Já que existe um repositório para Unidade, ele poderia utilizar o modelo de entrada UnidadeInputModel, mapear para a entidade Unidade, e realizar a chamada do método do repositório. Quanto a consulta, poderia chamar o método ObterTodos do IUnidadeRepository, e mapear para lista de UnidadeItemViewModel.

Serviço de Aplicação

Commands e Queries

Uma alternativa à implementação convencional da Clean Architecture, que utiliza de Serviços de Aplicação, é o padrão CQRS. Não é o objetivo deste artigo entrar em detalhes no CQRS (vai rolar um artigo sobre ele futuramente!), mas acho importante apresentar essa opção.

Ao invés de chamar o Serviço de Aplicação desde os Controllers, você poderia utilizar a biblioteca MediatR, que implementa o padrão Mediator, e deixar que ela selecione os QueryHandler/CommandHandler respectivos para tratar os dados de entrada. Além disso, no padrão CQRS geralmente as entradas da API são Commands, e a Query seria montada com base nos parâmetros e QueryString da URL.


Resultado

Logo abaixo eu deixo a estrutura resultante da camada Application.

Serviço, Modelo de entrada e Modelo de saída no Gerenciador de Solução

Já pensou nos resultados incríveis que você pode ter com o meu acompanhamento em sua carreira, com foco em te ajudar a definir, acompanhar e conquistar seus objetivos? Sejam eles a respeito de especialização técnica, promoções de cargo, reconhecimento, conquistas financeiras, reconhecimento de comunidade e/ou carreira internacional.

Tenho um Programa de Mentoria em Grupo focado em desenvolvedores .NET, e estou recebendo aplicações. Se tiver interesse real em contar com minha ajuda nisso, clique aqui e preencha o formulário.


Conclusão

Eu evito ao máximo impor padrões e estruturas. Acho que o Clean Architecture oferece muito valor em sua essência, e que é possível personalizá-lo de acordo com o seu projeto. Isso, claro, desde que ele não perca suas vantagens.

Recomendo dar uma sacada no código-fonte, para se certificar de que compreendeu as propriedades e estrutura que usei lá.

E você, como implementa ele em seus projetos? Compartilhe esse artigo com sua equipe, para gerar uma discussão (saudável, de preferência!) entre si.

Até a próxima!