Domain Driven Design (DDD) é uma abordagem arquitetural criada por Eric Evans que busca resolver a complexidade central de sistemas complexos, focando na comunicação e modelagem do negócio através de uma linguagem ubíqua. O DDD enfatiza a identificação de domínios e subdomínios, delimitação de contextos e utilização de entidades e objetos de valor para representar a lógica do negócio, sem se prender a tecnologias específicas. Seu objetivo é entender e definir a complexidade do sistema antes de codificar, garantindo que as soluções reflitam a realidade do negócio.

1. DOMAIN DRIVEN DESIGN
Jefferson Mariano de Souza

2. DEFINIÇÃO
abordagem arquitetural
forma de diminuir a complexidade do coração do
sistema
delimitar contextos
lado mais filosófico do que técnico

3. FORMA DE DIMINUIR A COMPLEXIDADE
DO CORAÇÃO DO SISTEMA
resolver o problema do negócio
resolver a parte principal do sistema

4. utiliza diversos design patterns, mas não está
acoplado a nenhum
Não se trata apenas de criar camadas, entidades,
repositórios etc
Design guiado pelo domínio (razão da aplicação
existir)

5. HISTÓRIA
Criado em 2003, por Eric Evans
"DDD é algo mutável, pode evoluir com o passar do
tempo"

7. QUANDO USAR?
aplicações complexas
sistemas que uma decisão errada pode impactar o
projeto inteiro

8. DOMÍNIO
o coração do negócio (razão do negócio existir)
tem base em um conjunto de ideias, conhecimento
e processos
sem domínio, os processos auxiliares não tem muita
utilidade

9. PARA RESOLVER O PROBLEMA DE
NEGÓCIO, NÃO PRECISAMOS
NECESSARIAMENTE DE CÓDIGO
Mas sim...

10. COMUNICAÇÃO
conseguir falar com todos os envolvidos em uma
mesma linguagem
conversar entre todas as áreas, com todos os
envolvidos no problema

12. LINGUAGEM UBÍQUA
é a linguagem falada no dia a dia no contexto da
empresa
utiliza as terminologias da realidade do negócio
desenvolvedores precisam conhecer a fundo a
linguagem do negócio
objetivo: conseguir modelar o sistema para
representar o negócio real

13. LINGUAGEM UBÍQUA
Exemplo: O que é "Cliente"?
quem loga no sistema?
quem compra algum produto?
quem contrata um serviço?

14. LINGUAGEM UBÍQUA

15. DOMAIN EXPERT

16. DOMAIN EXPERT
quem conhece profundamente o negócio
quem vive o dia a dia do negócio

17. Com a comunicação em ordem
Domínio bem definido
o próximo passo é identificar subdomínios

18. IDENTIFICAR SUBDOMÍNIOS
Domínio é o core business, o coração do problema

19. SUBDOMÍNIO
subáreas do sistema que possuem complexidades e
diversas regras
refle muito em como a empresa vai funcionar

20. IDENTIFICAR CONTEXTOS DA
EMPRESA
cada contexto tem sua própria forma, sua própria
linguagem
as complexidades mudam de acordo com cada uma
das áreas

22. COMUNICAÇÃO ENTRE OS
CONTEXTOS
apesar de cada contexto ser delimitado, geralmente
um precisa se relacionar com o outro

23. identificar quais são as partes do domínio principal
identificar quais são os domínios auxiliares
identificar relações entre os domínios

24. MAPA DE CONTEXTO
mapa que detalha a relação entre os domínios
possibilita uma visão geral do sistema
separar os pontos de complexidade
identificar pontos auxiliares para o sistema
conseguir atacar o que realmente importa

26. RESUMINDO: PILARES DO DDD
linguagem ubíqua
contextos delimitados (bounded contexts) - até
onde vai a reponsabilidade de cada parte do
sistema
mapas de contexto - comunicação entre os
contextos

27. E NO CÓDIGO?
Entidades
Objetos de Valor
Agregações
Repositórios
Serviços

28. tudo baseado na linguagem criada antes de chegar
no código
só começa o código quando a complexidade for
definida e entendida

29. A maior parte do esforço está na parte de entender a
complexidade

30. ENTIDADE
algo único no sistema, com representatividade no
negócio
existe no sistema, pode mudar seu estado
este item geralmente possui um id (que não existe
por existir, mas para diferenciar um do outro)
é um domínio rico, tem uma razão de existir

31. Cada contexto tem suas próprias entidades
Posso ter a entidade "Cliente" em mais de um
contexto
uma entidade pode aparecer em diversos contextos
com nomes diferentes

32. EXEMPLO: CADASTRO DE USUÁRIO
QUAL O TIPO DE DADO?
nome
cpf
email

33. OBJETO DE VALOR
classe que não tem identidade única, é usada como
auxiliar
(parar de usar tipos primitivos para tudo)
CPF -> possui validação própria
E-Mail -> possui validação própria

35. AGGREGATES
Relação Pedido x item
Pedido possui N itens
Item só existe se existir pedido

36. Pedido: Raiz, por onde o processo começa
Pedido: Root Aggregate

37. REPOSITÓRIO
Parte responsável por persistir as entidades
Geralmente existe apenas para o aggregate root
Ex: eu persisto o pedido, não o item

38. SERVICE
Operação que não é uma parte natural de uma
Entidade ou Objeto de Valor
Geralmente relacionada a um conceito de domínio
É uma operação definida em termos de outros
elementos do modelo
Geralmente é uma operação stateless

39. CONCLUSÃO
DDD é bastante amplo
Foco no negócio
Não se prende a uma tecnologia específica (não é
framework da moda)
Não é só trabalhar com services e
repositories

40. PARA SABER MAIS
Domain Driven Design - Eric Evans
Domain Driven Design Distilled - Vernon Vaughn

41. OBRIGADO
Apresentação disponível em:
https://studiojms.github.io/domain-driven-design-
introduction