Implementando na prática Rest API com conceitos de DDD + .NET CORE + SQL no Docker + IoC

Todo desenvolvedor já se perguntou, como implementar o conceito de DDD em seu código?. Portanto se você entrou neste artigo, provavelmente é porque está procurando algum artigo que explique no detalhe uma arquitetura usando o conceito de DDD(Domain Drive Design).Neste post, falaremos de como implementar esses conceitos em uma solução de Rest API com .Net Core 3.0 e com SQL Server como virtualização no Docker.

Antes de mais nada, vamos iniciar uma pequena introdução ao conceito de Domain Drive Design para que possamos entrar no conteúdo técnico.

O que é DDD (Domain Drive Design)?

Domain Driven Design significa Projeto Orientado a Domínio. Ele veio do título do livro escrito por Eric Evans, dono da DomainLanguage, uma empresa especializada em treinamento e consultoria para desenvolvimento de software. O livro de Evans é um grande catálogo de Padrões, baseados em experiências do autor ao longo de mais de 20 anos desenvolvendo software utilizando técnicas de Orientação a Objetos. O que seria um Padrão?

Um padrão é uma regra de três partes que expressa a relação entre um contexto (1), um problema (2) e uma solução (3).

DDD pode ser visto por alguns como a volta da orientação a objetos. É verdade que o livro é um chamado às boas práticas de programação que já existem desde a época remota do SmallTalk. Quando se fala em Orientação a Objetos pensa-se logo em classes, heranças, polimorfismo, encapsulamento. Mas a essência da Orientação a Objetos também tem coisas como:

• Alinhamento do código com o negócio: o contato dos desenvolvedores com os especialistas do domínio é algo essencial quando se faz DDD (o pessoal de métodos ágeis já sabe disso faz tempo);
• Favorecer reutilização: os blocos de construção, que veremos adiante, facilitam aproveitar um mesmo conceito de domínio ou um mesmo código em vários lugares;
• Mínimo de acoplamento: Com um modelo bem feito, organizado, as várias partes de um sistema interagem sem que haja muita dependência entre módulos ou classes de objetos de conceitos distintos;
• Independência da Tecnologia: DDD não foca em tecnologia, mas sim em entender as regras de negócio e como elas devem estar refletidas no código e no modelo de domínio. Não que a tecnologia usada não seja importante, mas essa não é uma preocupação de DDD.

Principais coisas que você precisa saber sobre o DDD

Não é uma arquitetura

Muitos programadores entendem que Domain Driven Design é uma arquitetura, embora existam vários textos e tutoriais falando de como se criar uma “Arquitetura DDD”, o Domain Drive Design (DDD) não é uma arquitetura por si só e sim um paradigma que é aplicado à arquitetura a qual você desejar criar ou seguir, e é isso que torna o DDD tão fantástico assim.

Não é uma tecnologia

Para você aplicar o DDD não é preciso nenhuma ferramente de terceiros para realizar essa implementação.

Caso use os conceitos de DDD, você terá um software…

• Responsável.
• Escalável.
• Testável.
• Com uma manutenção fácil e tranquila.
• E escrito com boas práticas.

Entendimento de uma arquitetura com os conceitos DDD

A imagem abaixo representa um ilustração de como será todas as camadas usando o conceito de DDD:

01- Camada de Apresentação

A camada de apresentação que é responsável por abranger tudo o que diz respeito as interações com o cliente. Nela pode ser:

• Aplicação Desktop (WinForms).
• Aplicação Web (Angular, React, Vue).
• Aplicação Mobile (Android).
• Aplicação de serviço (WCF, Rest Api).

02 - Camada de Aplicação

A camada de aplicação que é responsável por realizar a(s) aplicação(s) se comunicar diretamente com o Domínio. Nela são implementados:

• Classes dos Serviços da aplicação.
• Interfaces (contratos).
• DataTransferObjects (DTO).
• AutoMapper

Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems. The tasks this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems. This layer is kept in thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of task for the user program.

Domain Driven Design, página 70.

A definição acima, foi retirada do livro e descreve o que é a camada de aplicação dentro do DDD. O ponto em negrito é extremamente importante quando se tenta entender as responsabilidades dos objetos que ali residem. Resumindo: Na camada de aplicação não é implementada nenhuma regra de negócio, ela somente coordena a execução de uma tarefa e delega para os objetos de domínio na camada inferior.

04 - Domínio

A camada de domínio que é responsável por ter um uma modelagem sólida e aqui que a mágica do DDD(Domain Drive Design) acontece. Nessa camada temos:

• Entidades.
• Interfaces (contratos) para Serviços e Repositórios.
• Classes dos Serviços do domínio.
• Validações (caso seja necessário).

04 - Infraestrutura

A camada de infraestrutura é responsável por dar o suporte as demais camadas. Que atualmente é dividida por duas camadas com seus respectivos conteúdos:

Data:

• Repositórios.
• DataModel (Mapeamento).
• Persistência de dados.

CrossCutting (camada que atravessa todas as outras, portando possui referência de todas elas):

A camada CrossCutting pode realizar a inversão de controle e injeção de dependências. Isso significa que você não precisará instanciar todas as classes manualmente.

• IoC (Inversão de controle).

Comunicação das Camadas

Após de ter o entendimento do funcionamento das camadas do conceito de DDD, agora iremos mostrar de forma de ilustração como que as camadas se comunicam :

Como podemos ver o que já foi explicado, todas as camadas possuem uma numeração sequencial, que se trata da forma em que o fluxo da arquitetura funciona, desde a camada de apresentação até a persistência de informações no banco de dados.

Bom Nerds, depois de entendermos o conceito do Domain Driven Design em uma teoria um pouco cansativa, espero que vocês tenham um entendido claro de como é o funcionamento do DDD e usando esses conceitos que vimos que iremos implementar uma solução de Rest API com .Net Core 3.0 e com SQL Server como virtualização no Docker. Agora entraremos no conceito mais técnico para ver na prática como tudo isso funciona no link abaixo:

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