DDD: Domain-driven design na prática
Este artigo é a continuação direta do primeiro artigo de introdução ao DDD, que está disponível no blog da GFT. Nele, exploramos os principais conceitos do Domain Driven Design. Falamos de uma forma direta sobre os princípios desse padrão de projeto e de como ele pode te ajudar a estruturar bem o seu próprio projeto.
Nessa etapa, vamos focar na aplicação dos conceitos apresentados, tentando novamente ser o mais objetivo possível no conteúdo, para trazer de forma direta a aplicação/estruturação de um projeto com DDD. Utilizaremos para este exemplo Visual Studio, .Net e C# como base para apresentar os tópicos.
Contextualizando o projeto
Fique tranquilo! Não partiremos de nada muito complicado para este exemplo, criaremos um projeto bem simples.
Vamos começar dividindo-o da seguinte forma:
- Camada de aplicação: será onde os controladores e serviços da API serão criados.
- Camada de domínio: será o “coração” do projeto. Onde serão implementadas as classes, modelos e interfaces do sistema e regras de negócio da aplicação. Algumas abordagens sugerem usar uma camada específica (services) para a estruturação das regras de negócio. Para nosso exemplo, usaremos as regras implementadas diretamente no domínio.
- Camada de infraestrutura: camada responsável por prover a camada de domínio os insumos necessários para que ela consiga processar as regras de negócio.
Estruturando o projeto
Ao estruturar o projeto, precisamos abstrair e aplicar os conceitos de DDD, trazendo agora para a estrutura do software, onde basicamente temos a seguinte disposição:
Observe que transcrevemos as camadas detalhadas acima em projetos separados dentro do Visual Studio, em que a aplicação é um website, o domínio e a infraestrutura são class library.
Com as camadas já definidas, agora entra a estruturação do projeto. Nessa etapa iremos separar logicamente os objetos que serão criados.
Nesse ponto vale lembrar que é exatamente aqui que aplicamos a linguagem ubíqua, onde todos os itens irão refletir a mesma terminologia utilizada pelos especialistas no negócio, para que a comunicação entre todos os times envolvidos no processo ocorra de forma fluida e natural.
Quando conseguimos definir quais são os termos que os especialistas no negócio mais irão utilizar, esta extração fará toda a diferença no processo de desenvolvimento e comunicação na aplicação. Quando utilizamos a Linguagem Ubíqua é muito importante que esteja tudo organizado e compartilhado.
Nesse momento, é importante levantar um ponto extremamente importante para o DDD: a delimitação de uma fronteira de trabalho (bounded contexts). Quando trabalhamos com DDD, crescemos a aplicação baseada no domínio. Com isso, temos que delimitar, dentro deste domínio, a responsabilidade de cada um dos módulos. Por exemplo, o módulo de endereço não pode fazer validações referentes ao nome.
Note que quando definimos um sistema utilizando DDD, conseguimos ter uma visão geral e separar as entidades, direcionando para o seu devido contexto.
Outra vantagem que temos é a independência das camadas. Como a base é o domínio, os projetos periféricos (neste caso, apresentação e infraestrutura) fazem referência somente ao domínio.
Este artigo demonstra que é possível fazer um projeto de pequeno porte utilizando os conceitos de DDD, criando uma nova arquitetura, além de utilizar várias classes genéricas para poupar trabalho no desenvolvimento, trazendo os conceitos de polimorfismo e encapsulamento.
DDD (Domain Driven Design) não é apenas separar as camadas, mas sim seguir todo um processo de desenvolvimento, desde entender o negócio com o especialistas de domínio, extrair a linguagem ubíqua, definir os contextos e criar o mapa de contexto para poder começar a trabalhar as entidades e desenvolver a aplicação.
