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
