Clean Architecture com ASP.NET Core – Parte #2

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

Nessa segunda parte da série, vou apresentar os componentes da camada Core, e criar as pastas e arquivos-base dela.

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 Core

Revisitando o que eu escrevi no artigo passado, a camada Core é constituída pelos seguintes componentes:

  • Entidades
  • Serviços
  • Interfaces
  • DTOs

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

Entidades

São as classes que representam os elementos do nosso domínio de negócio, que serão persistidos, consultados e filtrados, alterados, etc.

Por exemplo, em um sistema de academia, entidades possíveis seriam:

  • Unidade (em caso de múltiplas unidades, é importante criar isso);
  • Aluno;
  • Funcionário (onde seria importante ter alguma propriedade ou relacionamento indicando o seu papel na academia);
  • Equipamento (para gerenciamento do estoque de equipamentos usados na academia).

Nosso projeto, com essas entidades, ficaria que nem a imagem abaixo. Já adicionei os Enums da camada de domínio nele, já que uso eles nas propriedades das entidades.

Entidades e Enums da camada Core

Serviços

Nessa camada, os serviços implementados são os de domínio. Lógicas mais complexas e/ou onde não é possível atribuir tanta responsabilidade a uma entidade apenas pela operação, são localizadas nesses serviços.

Um exemplo clássico é o de transferência entre contas de um banco. Será que uma entidade apenas deve ser responsável por coordenar as verificações de saldo, débito de sua conta, crédito em outra, e atualização de saldos? Parece ser muita responsabilidade para uma entidade apenas, certo? Nesse caso, um serviço de domínio para tratar essas condições de transferência seriam mais adequados.

Poderíamos ter um serviço, em nosso domínio de academias, para gerenciar a inscrição de alunos em turmas de alguma atividade como arte marcial ou dança. Seriam feitas checagens de disponibilidades, validade da conta do usuário, registro de pedido (tipo um protocolo). Não falo de integrações entre sistemas nessas atividades, trato apenas de checagem de regras de negócios, e como coordenar elas em um serviço de domínio.

Nosso projeto, com esse serviço, ficaria que nem a imagem abaixo.

Services na camada Core

Interfaces

As interfaces contidas na camada Core podem ser relativas ao:

  • Domínio (serviços)
  • Infraestrutura (acesso a dados, recursos de nuvem, integrações com outros sistemas, etc)

É comum encontrar aqui interfaces de repositórios, padrão utilizado para implementar o acesso a dados da aplicação.

Nosso projeto, com essas interfaces, ficaria que nem a imagem abaixo.

Interfaces na camada Core

Você pode separar os serviços entre Infraestrutura e Domínio. Não problema algum em fazer isso, é até recomendado dependendo da quantidade de serviços em sua aplicação!

DTOs

DTOs são classes simples, que não são entidades do domínio, e que podem ser utilizados por serviços ou interfaces.

Por exemplo, é comum utilizar DTOs para retorno de consultas de repositórios no padrão CQRS, já que é vantajoso realizar projeções dos dados consultado, não necessariamente trazendo entidades do domínio da consulta do repositório. Também é comum utilizar eles em interfaces de serviços de integração entre sistemas, já que os objetos podem variar bastante de estrutura.

Nosso projeto, com DTO, ficaria que nem a imagem abaixo.

DTO no projeto Core

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 personaliza-lo de acordo com o seu projeto. Isso, claro, que ele não perca exatamente 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 preferencia!) entre si.

Até a próxima!