Estruturando Arquitetura API .Net Core 2.2

Introdução

No artigo de hoje vamos estruturar uma web API .Net Core 2.2, separando em API, Domain, Repository e Services, utilizando o conceito de interfaces e clean code.

Mão na Massa

Vamos criar um novo projeto web no Visual Studio

Selecione API e utilize o Core 2.2

Após a criação, vamos ter essa estrutura no projeto:

O objetivo é criar outros projetos dentro da nossa solução e deixar cada um com sua respectiva responsabilidade.

Vamos criar os projetos:

Api: Irá conter as chamadas das nossas APIs.

Domain: Irá conter as entidades do nosso sistema (Dominios Ricos).

Repository: Onde será realizado as interações de persistência.

Service: Onde será realizado a regra de negócio em caso necessário.

Cada classe criada dentro da service e repository terá seu respectivo contrato (Interfaces).

Criando os projetos:

Clique com o botão direito em cima da Solution e crie um novo projeto.

Em seguida, selecione o projeto Biblioteca de Classes (Class Libary) e adicione o nome do projeto, lembrando que vamos criar uma class libary para cada projeto mencionado.

No final, teremos essa estrutura:

Agora que nossos projetos estruturados já estão estruturados, vamos criar um controller chamado HeroContolle e um endpoint do tipo Post chamado HeroApi.

Esse endpoint irá receber alguns parâmetros, mas em vez de adicionar N parâmetros no escopo do método, vamos criar uma classe chamada HeroDto, um padrão de projeto para transferencial de dados entre camadas.

Nossa heroDto terá essa estrutura:

Agora que já temos nossa DTO, vamos criar nossa Model dentro do projeto Domain chamada Hero.

Note que em nossa classe tem um construtor, e o atributos dela são privados ou seja, um Hero só é criado dentro da classe Hero. Dessa forma, evito que meu objeto seja alterado no decorrer do processo.

Agora que já temos nossa model, vamos criar nossa classe service com o nome HeroService.

Note que vamos utilizar nesse momento o conceito de contratos (Interfaces). Basicamente, a service irá ter contratos para ser acessada, ou seja, nossa controller não conhece a HeroService. Ela conhece o contrato da classe. Se por algum motivo a classe HeroService for alterada, as camadas acima não são impactadas.

Vamos criar a interface IHeroServices, que contém apenas a assinatura do método, ou seja, a controler sabe que tem que chamar um IHeroService.Hero. Ela não sabe, porem, quem implementa essa interface. Dessa forma, começamos a isolar os pontos do sistema:

Agora vamos herdar nossa interface na classe heroService.

Dentro da services vamos adicionar a regra de negócio. Se o nome do hero for “Iron Man”, vamos adicionar uma lista de string, apenas para simular uma regra de negócio em nossa service.

Agora devemos criar a HeroRepository e ajustar a HeroService, utilizando o mesmos conceitos de interfaces.

Na repository não vamos nos aprofundar. Vou retornar apenas o hero. Nos próximos artigos, vamos utilizar o Dapper para realizar a persistência de dados.

Vamos voltar a HeroService e utilizar a IHeroRepository:

Note que criamos uma propriedade readOnly do tipo IHeroRepository e passamos ela para o construtor da classe, funcionando através da injeção de dependência do .Net Core.

Vamos fazer a mesma coisa na controller, só que agora vamos adicionar a service.