DDD – Introdução ao tema

 

O que é DDD?

DDD – Domain Driven Design ou Design orientado a domínio – é o negócio, o cliente, os processos. Ou seja: tudo que envolve um problema, focando não apenas em resolvê-lo, mas também na solução.

É a resolução e o entendimento do domínio do negócio de forma crescente, focados na junção dos especialistas do negócio e dos especialistas do desenvolvimento de forma que seja usada uma linguagem ubíqua (termos bem definidos, uma linguagem padronizada e entendível por todas as partes – uma linguagem natural, iterativa, fluente, universal). 

Domínio é o problema a ser resolvido, o alvo.

Modelo de domínio é o código, o foco principal.

DDD não é uma bala de prata. 

DDD não é uma arquitetura (Mas afeta sim nas decisões arquiteturais do software). 

DDD é uma “metodologia”, um mindset, que costuma ser mais eficiente e melhor aplicada em domínios complexos, além de exigir muito da comunicação e engajamento de todas as partes envolvidas. Comunicação esta que ajuda a identificar os substantivos mais relevantes para criar classes e relações, os verbos para criar o comportamento dentro do domínio e um sistema com grande cobertura de teste eficazes.

 

Como aplicar o DDD?

Uma das missões do DDD é “dividir para conquistar”; ou seja, identificar os contextos no domínio com base nas intenções do negócio e relacioná-los de forma correta. 

Contexto é algo que relaciona com o fato ou circunstância.

Contexto delimitado (bounded context) é quando o elemento do contexto tem um significado bem definido, sua própria linguagem ubíqua, sua própria arquitetura e implementação.

Exemplo: Uma plataforma de vendas de cursos online.

 

 

Essa plataforma tem muitos contextos e linguagens, como por exemplo: Curadoria, Financeiro, Certificados, Marketing e Vendas. 

O domínio começa a ficar muito grande quando começa a ter vários contextos, daí vira uma “grande bola de lama” ou, como é conhecida nos estudos de DDD: big ball of mug.

 

Por exemplo a entidade Curso abaixo:

 

  • Nome pode ser do contexto de Curadoria, uma vez que são eles que criam os novos cursos.
  • TemCertificado faz parte do contexto Certificados
  • ApareceNaVitrinePrincipal e TotalDeVisualizacoes são do contexto de Marketing
  • Preco pode fazer parte do contexto de Vendas ou do Financeiro.

 

Tentar colocar todo o do contexto da empresa em um só domínio fere diversos princípios do SOLID e do Clean Code, além de ser trabalhoso, difícil de dar manutenção, de entender posteriormente e de relacionar. 

 

 

Nessa imagem, utilizamos os conceitos do domínio (Curso) em cada contexto.

A entidade Curso não será necessariamente replicada nos contextos uma vez que cada contexto tem uma própria linguagem, as propriedades do domínio serão diferentes.

Por exemplo em Financeiro, o curso terá apenas relação com coisas do financeiro, e etc.

E cada contexto também pode utilizar diferentes arquiteturas, camadas de aplicação, persistência, infraestrutura, etc.

Cada contexto irá se comunicar/relacionar por uma interface externa criada posteriormente.

Context Map: É necessário desenhar os bounded contexts para que a aplicação e seus relacionamentos sejam vistos de forma global. Existem diversos padrões para descrever esses relacionamentos do context map. Aqui vou falar do Downstream e Upstream (Cliente e Fornecedor): Downstream (ou customer) dependem dos Upstream (supplier). Se uma equipe que cuida do Upstream alterar algo de forma errada, o Downstream é afetado negativamente. 

 

É interessante que tenham testes de aceitação automatizados para validar as interfaces que as equipes de Upstream fornecem.

 

 

Arquitetura

O DDD não obriga o uso de alguma arquitetura específica.

É necessário concentrar o esforço para desenhar o domínio no coração da aplicação e essa não pode ter dependência externa com nada – ou seja: não pode acessar nada, apenas ser acessada.

A aplicação deverá ser separada em camadas bem definidas.

 

Exemplo: Onion

 

 

E como fazer o core da aplicação de forma independente?

Inversão de dependência: camada inferior não pode depender da camada superior.

Ambos dependem de abstração.

Abstração não deve depender de detalhes, detalhes que devem depender de abstração.

 

Exemplo:

 

ICursoRepositorio é uma abstração, uma interface que representa o contrato necessário para salvar o curso.

CursoRepositorio é uma classe que implementa o detalhe.

CriacaoDeCurso não chama diretamente a CursoRepositorio, chama a abstração.

 

DICA: Externalizar infraestrutura e escrever adaptadores para que a infraestrutura não se torne acoplada.

 

 

O que o DDD fornece para a criação de domínio?

  • Entidades – É um conceito de domínio que tem importância individual. Exemplo: Entidade Pessoa. Tem as propriedades Nome, CPF, Email, NomeRua, NomeBairro, CepRua, NomeCidade e um Id, que é o identificador para distinguir uma pessoa de outra.
  • Objetos de Valor (Value Object) – É um pequeno objeto que representa uma simples entidade, mas não possui identificador. É imutado. Dois VO são iguais quando seus valores são os mesmos. Exemplo: Alterar a entidade pessoa, colocando uma propriedade do tipo Endereco, remover os campos NomeRua, NomeBairro, CepRua, NomeCidade e coloca-los no VO Endereco. Quando for mapear para tabela, só vai existir a tabela Pessoa, mas os campos do VO Endereco irão existir.
  • Encapsulamento – Esconder detalhes internos e ter responsabilidades sobre os dados. Isolar o objeto. Facilita a manutenção do código, reutilização e divide as responsabilidades. 

 

Por fim, o DDD só é possível com a colaboração de quem entende do negócio (domínio) e de quem sabe criar o software durante todo o processo. O software só é bem construído se for bem guiado pelo conhecimento e modelagem do negócio antes de aplicar qualquer tecnologia. 

 

Caso queira saber mais sobre como começar a desenvolver utilizando essa metodologia (lembra né? O DDD não é uma arquitetura…) e aprofundar no tema, é interessante estudar sobre as Arquiteturas Hexagonais (que são as camadas bem definidas de um desenvolvimento de software), princípios de SOLID, Clean Code, TDD… 😊

 

Tem também dois livros bem famosos, praticamente todos artigos que li e o curso que fiz citam eles, são esses: 

  • Domain Driven Design – Blue book do Eric Evans 
  • Implementing Domain-Driven Design – do Vaughn Vernon 

Sendo o segundo considerado mais interativo e de fácil compreensão. 

 

Bom, é isso. Espero ter ajudado a entender, pelo menos um pouco, do que é o DDD.

 

Autora: Gabriella de Aquino Xavier

Especialista em Desenvolvimento

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *