Implementando na prática Rest API com conceitos de DDD + .NET CORE + SQL no Docker + IoC -[Parte Técnica]

Daniel Jesus
Bee Lab Academy
Published in
8 min readOct 27, 2019

--

Dando continuidade nesse tema interessante que é o Domain Driven Design, agora entraremos na parte que todo desenvolvedor gosta que é a parte técnica.

Caso esteja vendo esse post e não chegou a ver o post que trata de assuntos teóricos, eu aconselho a você dar uma lida no post anterior clicando aqui, lá explico como funciona a arquitetura que iremos montar do zero neste post usando os conceitos de Domain Driven Design.

Ambiente de Desenvolvimento

A seguir vamos utilizar a linguagem C#, onde todos os projetos foram criados em .NET Core versão 3.0 no Visual Studio 2019. Também é importante ressaltar que conhecimentos de polimorfismo e encapsulamento são premissas para este artigo, uma vez que iremos criar classes genéricas para poupar muita repetição de código.

Portanto vale ressaltar as outras ferramentas que iremos usar no nosso ambiente de Desenvolvimento que são:

  • Docker + Kitematic.
  • Visual Studio 2019.
  • Framework 3.0 do .Net Core.
  • Microsoft Sql Management

Configuração do SQL Server no Docker

Agora entraremos no tema de configuração da virtualização do SQL que iremos realizar dentro do Docker.

No meu caso que uso a plataforma Windows, irei abrir o Windows Power Shell e digitar o comando a baixo:

Comando:

Sugestão:

O comando está com a senha “ yourStrong(!)Password’ ”, mas fique a vontade de mudar!

Executar o SQL no Docker

Iremos abrir o software Kitematic para visualizar a virtualização do SQL que realizamos a configuração no tópico de cima.

Como vimos existe uma imagem que se refere a sql, isso iremos clicar em cima e executar o container informado.

Depois de deixarmos o ambiente pronto, vamos partir para a montagem da arquitetura usando .Net Core 3.0.

Montando a Arquitetura .Net Core

Depois de entendermos no conceito o que é DDD (Domain Drive Design), entraremos agora na parte técnica de como realizar uma Arquitetura em Rest API aplicando tudo que vimos até momento.

Primeiramente iremos criar uma solução Asp Net Core Web Application.

Camadas

A partir da criação da solução Rest API, iremos aplicar os conceitos de DDD em nosso código.

Primeiramente iremos realizar a organização por pastas que representará as camadas que vimos no DDD, que serão:

  • Presentation (Apresentação).
  • Application (Aplicação).
  • Domain (Domínio).
  • Infrastructure (Infraestrutura).

Camada de Domínio

Primeiramente iremos iniciar codificando pela camada de domínio, pois como vimos anteriormente essa camada é o única que não depende das outras camadas.

Atenção: Portanto Nerds, reparem bem aos códigos, pois estamos criando classes “Base” para tudo, isso nos permite reaproveitar propriedades e métodos de forma genérica.

Como iremos criar um serviço de ecommerce, iremos começar a modelar as nossas entidades e pra isso precisamos criar um projeto “DDDWebAPI.Domain” do tipo Class Libray (.Net Core) em C#.

Depois crie uma pasta chamada “Models” que existirá entidades do nosso projeto.

Entidades:

Entidade Base
Entidade Cliente que herda a entidade Base
Entidade Produto que herda a entidade Base

Agora iremos criar um novo projeto na camada de domínio do tipo do tipo Class Libray (.Net Core) em C#.

Esse projeto se refere uma camada de domínio que armazenará as interfaces dos repositórios patterns e do services do domínio.

As interfaces que criaremos a seguir, são as mesmas que serão implementadas nas classes de repositórios patterns e do services do domínio na camada Infraestrutura.

Interfaces dos repositórios

IRepositoryBase
IRepositoryCliente herda as assinaturas dos métodos da interface base repositório passando a entidade cliente.
IRepositoryProduto herda as assinaturas dos métodos da interface base repositório passando a entidade produto.

Por último para finalizarmos a nossa camada de domínio com chave de ouro, iremos implementar um novo projeto chamado “DDDWebAPI.Domain.Services” do tipo Class Libray (.Net Core) em C#.

Esse projeto se refere a classes que que terão métodos genéricos que são comuns em cadastro de cliente e produto como inclusão, remoção e atualização. Portanto perceba que abaixo é esperado como parâmetro a interface do tipo de repositório que criamos acima, mas não vamos falar sobre esse poderoso pattern de repositório agora, isso é assunto que iremos tratar na camada de Infraestrutura, que vamos ver mais abaixo.

Service Base
Service Cliente
Service Produto

Camada de Aplicação

Após preparar a camada Domínio, vamos agora criar a estrutura da camada de Aplicação, a qual se comunicará diretamente com o Domínio. Então criaremos dois projetos um chamado “DDDWebAPI.Application” e outro chamado DDDWebAPI.Application.DTO do tipo Class Libray (.Net Core) em C# e esses projetos terão a dependência do projeto “DDDWebAPI.Domain.Core”, para que tenhamos acesso as informações das classes desse projeto.

No projeto “DDDWebAPI.Application.DTO” será responsável por armazenar nossos DTOs que serão utilizados nessa solução que estamos criando.

DTO: Objeto de Transferência de Dados (do inglês, Data transfer object, ou simplesmente DTO), é um padrão de projeto de software usado para transferir dados entre subsistemas de um software. DTOs são frequentemente usados em conjunção com objetos de acesso a dados para obter dados de um banco de dados.

Criaremos classes como ClienteDTO e ProdutoDTO que serão alimentados via requisição do nosso Rest API e trafegados na camadas da solução.

Entidade ClienteDTO
Entidade ProdutoDTO

No projeto “DDDWebAPI.Application” será responsável por armazenar nosso service e as interfaces que serão utilizados nessa solução que estamos criando.

Interfaces

IApplicationServiceCliente
IApplicationServiceProduto

Implementação dessas Interfaces Services

ApplicationServiceCliente
ApplicationServiceProduto

Camada de Infraestrutura

Como vimos já deixamos pronto as camadas Domínio e Aplicação e agora iremos dar início a preparação da camada Infraestrutura que se divide em IoC e Data.

Data

Esta subcamada é praticamente o coração da camada Data, é onde persistiremos todas as informações, onde comunicaremos com o banco de dados propriamente dito.

DDDWebAPI.Infrastructure.Data: Este projeto se refere o contexto de informações que são tratadas via banco de dados .

SqlContexto: Classe que herdamos o DbContext do EntityFrameWork, responsável por abrir transações e commita-las após término da persistência.

Classe SqlContext

DDDWebAPI.Infrastruture.Repository: Esta subcamada é praticamente é a implementação do pattern repositório.

Como vamos usar recursos da camada Domínio e da subcamada Data , vamos adicionar essas dependências neste projeto.

Pacotes NuGet: vamos precisar instalar 2 pacotes do NuGet:

  • Microsoft.EntityFrameworkCore (3.0).
  • Microsoft.EntityFrameworkCore.Sql (3.0).

Repositorios: onde são realizadas as consultas, inserções e atualizações nas tabelas do banco de dados, tudo isso usando o contexto, que criamos acima.

RepositoryBase
RepositoryCliente
RepositoryProduto

CrossCutting

Nessa pasta de CrossCutting, iremos criar dois projetos e um deles será chamado “DDDWebAPI.Infrastruture.CrossCutting.Adapter” e outro chamado DDDWebAPI.Infrastruture.CrossCutting.IOC do tipo Class Libray (.Net Core) em C# e esses projetos terão a dependência dos outros projetos:

DDDWebAPI.Infrastruture.CrossCutting.Adapter: Este projeto terá interfaces e classes que serve para que registrar no AutoMapper as classes Entidade e DTO, para que seja possível realizar a conversão de uma para a outra.

Interfaces

IMapperCliente
IMapperProduto

Implementação das Interfaces Mappers

MapperCliente
MapperProduto

DDDWebAPI.Infrastruture.CrossCutting.IOC: Este projeto terá o papel de implementar dependency injection ou em português injeção de dependências.

Pacotes NuGet: vamos precisar instalar 1 pacote do NuGet:

  • AutoFac(4.9.4).

Agora criaremos a classe ConfigurationIOC que será responsável por realizar a criação de um container IoC para registrar todas as instâncias das classes do nosso projeto.

ConfigurationIOC

Agora criaremos a classe ModuleIOC que será responsável por realizar a criação de um módulo que realizará leitura do meu container IoC para ler todas as instâncias das classes do nosso projeto.

ModuleIOC

Camada de Apresentação — Serviço Rest API

Acabamos de terminar de codificar as camadas Domínio, Aplicação e Infra, agora vamos fazer a nossa última camada.
Como escolhemos fazer uma API para a camada de Apresentação, como sabemos que é através dela que as aplicações se comunicarão com a nossa arquitetura, para que possamos buscar ou persistir informações.

Pacotes NuGet: vamos precisar instalar 1 pacote do NuGet:

  • AutoFac(4.9.4).
  • AutoFac.Extensions.DependencyInjection (5.0.1)
  • Microsoft.EntityFrameworkCore (3.0).
  • Microsoft.EntityFrameworkCore.Sql (3.0).

Caso você nunca criou um projeto Rest API em .Net Core, não se preocupe. Agora iremos criar as controllers do nosso serviço. Então abaixo temos as implementaççoes dos Controllers que iremos usar, conforme imagem abaixo.

ClientesController
ProdutosController

Classe Startup

Iremos realizar abaixo a configuração do contexto de conexão a base de dados.

Abaixo realizamos o registro do Módulo do Container IoC na inicialização do serviço Rest Api.

Arquitetura em camadas utilizando o conceito de DDD está pronta !!!

Depois de termos feito tudo isso, precisamos tentar entender de forma mais prática como o fluxo do conceito de Domain Driven Design funciona.

Portanto, de maneira mais direta e resumida, a imagem abaixo mostra fielmente como o fluxo do conceito de Domain Driven Design .

Vendo a figura acima, podemos ver que uma camada chama a outra, atendendo de forma clara as suas responsabilidades únicas, assim como vimos no post anterior .

Conclusão

O grande objetivo deste artigo foi mostrar e explicar um pouco sobre DDD e criar uma arquitetura robusta e escalável em camadas que consiga aplicar os paradigmas impostos pelo Domain Driven Design.

Espera-se que este artigo tenha contribuído com o conhecido que foi passado aqui e ter ajudado muitas pessoas que tem dúvidas ou dificuldades para implementar um arquitetura com DDD que realmente atenda.

Recomendo que leiam o livro “Domain Driven Design” escrito por Eric Evans para que possam abranger o conhecimento nesse assunto.

Referências:

Domain-Driven Design: Tackling Complexity in the Heart of Software

.NET Core 3.0 e ASP.NET Core 3.0: Guia de Referência

AutoFac

--

--

Daniel Jesus
Bee Lab Academy

Sênior Software Engineer, Technical Writer and Speaker, Microsoft Certified Professional