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.
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.
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.
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.
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.
Quer alavancar sua carreira como Desenvolvedor(a) .NET?
Opa, aqui é o Luis Felipe (LuisDev), criador do blog LuisDev.
Além de Desenvolvedor .NET Sênior, eu sou instrutor de mais de 700 alunos e também tenho dezenas de mentorados.
Conheça o com mais de 800 video-aulas sobre C# e desenvolvimento de APIs com ASP NET Core, Microsserviços com ASP NET Core, Arquitetura de Software, Computação em Nuvem, SQL, HTML, CSS e JavaScript, JavaScript Intermediário, TypeScript, Desenvolvimento Front-End com Angular, e Desenvolvimento Front-end com React. Diversos mini-cursos disponíveis aos alunos e atualizações gratuitas.
Suporte dedicado, e comunidade de centenas de alunos.
Completo e online, destinado a profissionais que querem dar seu próximo passo em sua carreira como desenvolvedores .NET.
Clique aqui para ter mais informações e garantir sua vaga
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!
Dev .NET Sênior com experiências para Irlanda e Estados Unidos, 2x Microsoft MVP, 9x Microsoft Certified, MBA em Arquitetura de Soluções, Fundador e Instrutor LuisDev Treinamentos,
