Arquitetura .NET: modelando aplicações com Domain-Driven Design Estratégico

Apresentando o projeto ContainRs - Apresentação

Olá! Boas-vindas ao curso de DDD Estratégico da Alura. Meu nome é Daniel Portugal, sou instrutor e desenvolvedor .NET, e acompanharei você ao longo deste conteúdo.

Audiodescrição: Daniel é um homem branco, de cabelos escuros, olhos castanhos e barba por fazer. Usa óculos de grau com armação quadrada e uma camiseta azul-claro. Ao fundo, um armário e uma parede lisa, a iluminação do ambiente é na cor azul.

Pré-requisitos

Para absorver bem o conteúdo deste curso, é essencial ter familiaridade com C-Sharp, orientação a objetos, persistência de dados com Entity Framework, desenvolvimento de APIs com AspNet Core e Minimal API, padrões de projeto, princípios SOLID e arquitetura limpa.

O que aprenderemos

Neste curso, exploraremos mais um padrão de design de códigos, focado no negócio, nos processos de negócio e nas áreas funcionais. Esse padrão é chamado DDD (Domain-Driven Design), e abordaremos a primeira parte, conhecida como DDD estratégico.

O DDD estratégico conta com diversas ferramentas que serão apresentadas ao longo do curso. Além de conhecê-las, analisaremos os cenários e situações em que cada uma deve ser aplicada. Com esse conhecimento, nossos projetos se tornarão mais compreensíveis, organizados e modulares.

Uma das principais transformações será na estrutura de projeto e solução no .NET. Em vez de termos baseados em conceitos técnicos e genéricos, como Endpoints, Requests e Response, aplicaremos o DDD estratégico para torná-los mais alinhados com os termos do negócio. Essa mudança facilitará a compreensão do que está sendo desenvolvido, ajudando a identificar as partes do código que precisam ser modificadas e tornando a solução mais modular.

Ao final do curso, teremos módulos bem definidos, como clientes e vendas, estruturados a partir dos conceitos do negócio. A abordagem será bastante prática, iniciando com uma introdução mais teórica e filosófica, para depois focaremos na escrita de código e aplicação dos princípios aprendidos. Nosso projeto será uma API, desenvolvida para uma empresa de aluguel de containers.

Para consolidar o aprendizado, é fundamental aproveitar todos os recursos disponíveis na plataforma. Além dos vídeos, há atividades complementares que aprofundam os temas abordados. O fórum da plataforma e a comunidade do Discord também são espaços ativos para troca de conhecimento e discussão.

Agora é hora de se preparar e mergulhar nesse assunto!

Apresentando o projeto ContainRs - Apresentando o projeto

Agora que já preparamos o ambiente, vamos apresentar o projeto que vamos desenvolver ao longo do curso.

Projeto do curso

Trabalhamos com uma empresa que aluga contêineres para diversas finalidades, como residências, escritórios e eventos, incluindo feiras e shows.

Nosso papel, como equipe de desenvolvimento, é gerenciar e manter uma API que dará suporte a um aplicativo para os clientes da empresa de contêineres. Para ilustrar um pouco sobre essa API, vamos abrir o Postman, faça o mesmo na sua máquina.

O Postman foi instalado durante a atividade de preparação do ambiente, assim como a coleção que disponibilizamos, contendo os endpoints e toda a configuração necessária para a API que vamos manter.

A API, chamada Contêineres API, está organizada em seis categorias. A primeira categoria, que aparece no topo, é a pasta "Identidade e Acesso", que contém os endpoints para autenticação e autorização. Na coleção, incluímos apenas dois endpoints, mas ao executar o projeto, perceberão que existem muitos outros, como recuperação de senha e autenticação em dois fatores. Tudo isso já está implementado, pois utilizamos uma biblioteca específica, sobre a qual falaremos em breve. Esses endpoints estão relacionados à Identidade e Acesso.

A partir da segunda pasta, começamos a abordar o processo de negócio da empresa de contêineres. O primeiro ponto de entrada do nosso aplicativo é o cadastro da pessoa cliente. Ela se cadastra de forma anônima, sendo um dos poucos endpoints sem proteção de acesso. Esse cadastro é então enviado para análise interna na empresa, que decidirá pela aprovação ou rejeição.

Se for aprovado, a pessoa cliente terá acesso ao aplicativo da Contêineres para realizar o aluguel de contêineres, atualizar endereço e dados, entre outras funcionalidades. Os endpoints relacionados a detalhes de clientes estão na pasta "Gestão de Cliente". Após isso, a pessoa cliente pode começar a fazer seus pedidos de aluguel, que estão na terceira pasta, chamada "Locação e Contratos".

Nessa pasta, temos endpoints para iniciar a solicitação de locação, para a pessoa vendedora enviar a proposta, para ajustes e, por fim, para a aprovação da proposta, recepção do contrato e visualização dos detalhes da proposta. Tudo isso está na pasta "Locação e Contratos".

Além disso, há endpoints para pagamento e faturamento, assim como para atendimento e suporte durante todo o ciclo de vida do cliente com a Contêineres. Essas funcionalidades estão nas pastas "Pagamentos e Faturamento" e "Atendimento e Suporte".

Por fim, temos uma última categoria de endpoints, chamada "Contêineres e Automação", que é utilizada quando o contêiner é disponibilizado para a pessoa cliente no local solicitado. Nela, a pessoa cliente tem acesso a detalhes sobre os contêineres e pode usar a automação para ligar a luz, verificar o status de energia, trancar o contêiner, entre outras ações.

Próximos passos

É importante mencionar que disponibilizamos uma série de endpoints na coleção, mas não implementamos todos no nosso projeto. Implementamos alguns endpoints para que possamos evoluir nosso conhecimento ao longo do curso.

Nisso, surge a pergunta: como está organizado o código? Quais são as tecnologias e bibliotecas utilizadas? E, principalmente, como é a arquitetura da API? Vamos abordar isso na sequência.

Apresentando o projeto ContainRs - Conhecendo a arquitetura do projeto

Agora que já conhecemos as funções da nossa API, representadas nos endpoints, surge a pergunta: como o código está organizado? Como estamos implementando essa API e esses endpoints no nosso projeto? Além disso, quais são os principais padrões e bibliotecas? Quais são os componentes de infraestrutura? E, por fim, isso tudo nos leva à compreensão da arquitetura desse projeto, desse software. Como ele está organizado e quais são suas camadas?

Recapitulando os componentes da arquitetura limpa

Vamos aproveitar para recapitular os componentes da arquitetura limpa. São quatro camadas:

• 1- Camada de domínio;
• 2- Camada de interface;
• 3- Camada de aplicação;
• 4- Camada de infraestrutura.

A camada de domínio abrange os conceitos e regras de negócio, a de aplicação refere-se ao fluxo de negócio atendido pelo projeto. Já a camada de interface trata das informações de entrada e saída do sistema e a de infraestrutura contém os componentes que implementam as principais responsabilidades do sistema, como persistência, cache, framework web e o modelo HTTP. Os componentes de infraestrutura que implementam essas funções precisam estar nessa camada.

Entendendo a comunicação entre camadas

Além disso, a arquitetura limpa possui uma regra rígida em relação à comunicação entre essas quatro camadas. Camadas mais internas não se comunicam com camadas mais externas.

No diagrama acima, mostramos a organização das camadas externas e internas. A camada de infraestrutura é a mais externa, seguida pela camada de interface, depois a de aplicação e, por fim, a de domínio. A camada de domínio é a mais isolada, não se comunica com nenhuma outra. Em contrapartida, a camada de infraestrutura pode referenciar todas as outras três.

Explorando a estrutura do projeto no Visual Studio

Será que conseguimos ver essa arquitetura limpa refletida no projeto? Vamos abrir o Visual Studio para conferir. Estamos com a solução Containers.api aberta no Visual Studio, faça o mesmo em sua máquina. Vamos começar analisando a estrutura de pastas dessa solução.

A estrutura de pastas está localizada no gerenciador de soluções, que, no nosso caso, está à esquerda do Visual Studio. Geralmente, fica à direita, mas optamos por essa organização na área de trabalho.

Temos dois projetos nessa solução, um projeto que é a API e outro que é um projeto de teste. Não há muitos testes, pois não nos preocupamos em criá-los, já que não serão necessários para a evolução do curso. Vamos focar no projeto ContainRs.Api.

No arquivo Program.cs, que é o arquivo de entrada de uma aplicação web ASP.NET Core, encontramos os componentes de infraestrutura, que serão organizados e configurados nesse arquivo.

Além disso, temos uma pasta chamada Data, onde provavelmente encontraremos as decisões e configurações de persistência do banco de dados, usando o EntityFrameworkCore.

Temos também uma pasta que se conecta diretamente com a camada de domínio, chamada Domain, onde estão os conceitos e, provavelmente, algumas regras de negócio.

Não conseguimos identificar muito mais em relação às camadas. Falamos da camada de infraestrutura e da camada de domínio. Quanto à camada de interface de entrada e saída e à camada de aplicação, podemos encontrá-las através de duas pastas, "Requests" e "Responses", pois sabemos que no modelo HTTP, o que chega ao sistema são as requisições.

Nessa pasta, temos tipos que representam os dados de entrada e saída. Provavelmente, também teremos informações para traduzir essas requisições para outras camadas e vice-versa. As informações que saem do modelo HTTP, que são as respostas a uma requisição, estão representadas na pasta "Responses".

Precisamos entender a camada de aplicação. Esta camada envolve os casos de uso e tudo o que é necessário para que esses casos sejam executados em forma de abstração, respeitando as regras de comunicação da camada de aplicação, que só pode se comunicar com a camada de domínio. Temos "Contracts" e "Endpoints", que representam a camada de aplicação.

A camada de contratos contém uma interface IRepository.cs, que é uma abstração referenciada nos endpoints. Para processar uma solicitação e informar seus detalhes, precisamos de um repositório de solicitação, que será implementado na camada de infraestrutura pelo Entity Framework para fornecer esses dados. Assim, os endpoints necessitam de uma abstração, que é o repositório. A camada de aplicação está representada nas pastas "Contracts" e "Endpoints".

Ao abrir a pasta "Endpoints", encontramos vários arquivos. No arquivo Solicitações Endpoints, temos a definição de todos os endpoints relacionados a solicitações. A inclusão de uma solicitação é feita pelo método MapPostSolicitação(), que é um caso de uso. O método MapGetSolicitações() também é outro caso de uso. O MapGetSolicitaçãoById(), próximo à linha 24, é mais um caso de uso, assim como o MapDeleteSolicitacao(). Os casos de uso estão representados pelos endpoints, e a camada de aplicação pode ser identificada através deles.

Agora, vamos explorar a infraestrutura. No arquivo Program.cs, identificamos a configuração de infraestrutura. Temos dois DbContext, dois contextos do Entity Framework Core, apontando para duas connections strings diferentes: uma para persistência da identidade, gestão de usuários, papéis, claims, e outra para o banco de negócios, que contém as solicitações, propostas, entre outros.

Além disso, temos a injeção de dependências de todos os repositórios necessários. Temos, por exemplo, o repositório de Cliente, Solicitacao, entre outros. Por fim, temos uma configuração da autorização e autenticação, que exigirá que o e-mail tenha sido confirmado e que alguns papéis tenham sido definidos. O armazenamento dessas informações está sendo feito pelo contexto do AddEntity. Por fim, temos os mapeamentos dos endpoints usando o ASP.NET Core, um framework da Microsoft para facilitar sistemas baseados em HTTP.

Identificamos as quatro partes da arquitetura limpa no projeto. A questão que fica é: será que essa arquitetura está sendo totalmente atendida? Existe alguma violação dos princípios e regras da arquitetura limpa? Deixamos essa atividade para reflexão. Talvez você já tenha identificado algo ao mexer no código do projeto. Vamos refletir sobre isso e, em seguida, discutir.

Sobre o curso Arquitetura .NET: modelando aplicações com Domain-Driven Design Estratégico

O curso Arquitetura .NET: modelando aplicações com Domain-Driven Design Estratégico possui 171 minutos de vídeos, em um total de 56 atividades. Gostou? Conheça nossos outros cursos de .NET em Programação, ou leia nossos artigos de Programação.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Apresentando o projeto ContainRs
• As áreas funcionais da empresa
• Aprofundando subdomínios
• Delimitando fronteiras
• Relacionando contextos