[PARTE 01] Criando arquitetura em camadas com DDD + Injeção de dep. + EF
Atalho para a Parte 02: aqui.
Se você entrou neste artigo, provavelmente é porque está procurando por alguma arquitetura DDD ou porque você precisa muito montar uma arquitetura robusta com injeção de dependências, ou senão, é porque você está aqui por curiosidade mesmo querendo aprender mais. Hehehe.
Como visto no título, esse artigo foi dividido em dois, devido a sua extensão houve esta necessidade de dividi-la em: “teoria” e “prática”.
Hoje o que iremos ver aqui é uma explicação sobre o DDD juntamente com a arquitetura que vou empregar. Vamos criar projetos e códigos na prática para exemplificar como funciona tudo isso.
Vamos mostrar que DDD nunca foi uma arquitetura e que instanciar alguns objetos é algo que podemos evitar usando IoC (Inversion of Control), que é TOP!
Antes de iniciarmos, já preciso dizer este artigo vai ser um pouco longo. Sim, tem muita coisa pra ler, mas não se preocupe, tem muita imagem e código (na parte 02) também, e te garanto que vai valer muito a pena no final! :)
Principais coisas que você precisa saber sobre o DDD
Não é 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.
O DDD é uma abordagem de modelagem de software que segue um conjunto de práticas com objetivo de facilitar a implementação de complexas regras / processos de negócios que tratamos como domínio. — Eduardo Pires
Não é uma tecnologia
Para você aplicar o DDD não é preciso nenhuma ferramente de terceiros para fazer isto.
O DDD não depende da tecnologia que você irá utilizar para fornecer sua aplicação, seja ela ASP.NET MVC, WebAPI, SPA, Windows Forms ou etc. — Eduardo Pires
Se por acaso você usar DDD, você terá um software…
- responsável.
- escalável.
- testável.
- de manutenção fácil e tranquila.
- escrito com boas práticas.
- muito massa!! :D
Você não precisa instanciar tudo para usar os benefícios do DDD!
É possível usar uma camada CrossCutting para realizar a inversão de controle e injeção de dependências. Isso significa que você não precisará instanciar todas as classes manualmente para que a mágica aconteça. Embora isso não seja algo importante para muitos projetos, mas para a nossa arquitetura será!
Entendendo a arquitetura com o DDD
Todas as camadas:
01- Apresentação
Camada responsável por abranger tudo o que diz respeito a interface de usuário (UI):
- Aplicação Desktop (WinForms)
- Aplicação Web (Angular, React, Vue)
- Aplicação Mobile (Android)
02 - Serviços
Toda forma de comunicação remota acontecerá aqui, muito usada em aplicação web, e nem sempre é implementada quando se trata de uma aplicação que consegue e suporta comunicar com a cama Aplicação (a seguir).
Algumas das implementações mais comuns:
- Web API (Http)
- SignalR
- WebSockets
03 - Aplicação
Camada responsável por fazer 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
04 - Domínio
Aqui é onde o DDD acontece! E nela nós temos:
- Entidades
- Interfaces (contratos) para Serviços e Repositórios
- Classes dos Serviços do domínio
- Validações (se necessário)
05 - Infraestrutura
Camada que da 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):
- IoC (Inversão de controle)
Quais as camadas que se comunicam umas com as outras
01 - Apresentação: recebe referência de “Aplicação”, “Domínio” e da “CrossCutting” (em “Infraestrutura”), em casos de aplicações front-end a comunicação é feita unicamente com a cama de “Serviços” (API, por exemplo).
02 - Serviços: recebe referência de “Aplicação”.
03 - Aplicação: recebe referência de “Domínio”.
04 - Domínio: embora seja a camada que mais da suporte às outras camadas, ela é a única que não recebe referência de ninguém, logo ela não depende de nada! Porem como mostra a imagem, ela se comunica de forma “indireta” com a camada Data (Infraestrutura), e isso só é possível graças à interfaces (sim, aquela que você assina o nome dos métodos, coisa e tal).
05 - Infraestrutura: por último, e não menos importante, temos esta camada que (como dito anteriormente) possui “subcamadas” Data e CrossCutting, onde recebem referência do domínio.
Data: tem o objetivo de persistir dados ou qualquer outra comunicação externa.
CrossCurring (Ioc): é onde registrados todas as interfaces e classes existente no projeto, para que o mesmo seja responsável por instanciar a árvore de dependências de toda a arquitetura.
Uma observação a arquitetura:
Como podemos ver, todas as camadas possuem uma numeração sequencial, e isso é muito importante, pois é exatamente desta forma em que o fluxo da arquitetura funciona, desde a interface gráfica até a persistência de informações no banco de dados.
OK OK! Vamos finalmente ver códigos!
Depois de uma teoria um pouco cansativa, espero que tenha entendido um pouco sobre como o DDD funciona em cima da arquitetura que vamos montar. Agora vamos ver como isso funciona na prática. Mas isto é na PARTE 02 desta jornada, aguardo vocês lá.
>> PARTE 02
