Uma rápida apresentação dos conceitos de domain driven design com uma pequena analogia com a foram tradicional de desenvolvimento.

1. Domain Driven Design
Daniel Everling
danieleverling@gmail.com

2. Quem Sou?
Profissional com mais de 8 anos de experiência
na área de desenvolvimento de aplicações web.
Graduado em Sistemas para Internet pela
Feevale.
Pós-Graduado em Engenharia de Software pela
Decision/Infnet.
Pós-Graduando em Arquitetura de Software pela
IGTI
Entusiasta quando o assunto é arquitetura,
qualidade de software, testes, clean code, DDD,
CQRS e Event Sourcing.

3. Entrevista com usuário
Precisamos ter segurado
com cpf, cnh e e-mail
válidos, N contatos, além
de poder adicionar
dependentes a apólice
de seguro.
OK, precisamos salvar
segurado em uma
tabela, validar seu CPF
e e-mail, e ter uma
tabela para salvar os
contatos, dependentes
e apólice de seguro

4. Como seria uma implementação deste cenário?

5. Da forma “tradicional”, teríamos algo como!

6. Da forma “tradicional”, teríamos algo como!

7. Da forma “tradicional”, teríamos algo como!

8. Da forma “tradicional”, pensamos em dados!
● Pensamos em dados, modelamos o banco de dados e fazemos nossas classes
“espelharem” um banco de dados
● Pensamos em camadas:
○ Camada de Apresentação;
○ Camada de Serviço;
○ Camada de Persistência.
● Utilizamos modelo anêmico, pois nossas classes são POJOs, e o negócio é
resolvido pela camada de serviço
○ Possuímos classes somente com DADOS outras somente COMPORTAMENTO.
○ Assim, DADOS e COMPORTAMENTO ficam desacoplados como unidades / componentes de
negócio.

9. Data Centric Model
DB

10. Reflexão!
1. Quantas vezes abrimos o modelo
ER durante a sprint?
2. No desenvolvimento da sprint,
debatemos mais sobre o negócio
ou sobre os dados?
3. Sabemos que objetos acoplados
são ruins, mas o acoplamento de
negócio entre camadas não é
pior?
4. Será que não programamos de
maneira procedural dentro de uma
linguagem Orientada a Objetos?

11. E o DDD?

12. Não é!

13. Domain Driven Design
● O DDD é uma abordagem de modelagem de software que segue um conjunto de
práticas com objetivo de facilitar a implementação de complexas regras /
processos de negócios que tratamos como domínio.
● Domain Driven Design como o nome já diz é sobre design. Design guiado pelo
domínio, ou seja, uma modelagem de software focada em resolver problemas na
complexidade do negócio.

14. O que é um domínio ?
Como seria o domínio desta fábrica ?
Provavelmente falaríamos de:
1. Esteira de Produção
2. Produtos / N domínio de Produtos
3. Trabalhadores
4. Logística
5. Almoxarifado
E cada um destes processos poderiam
ser um sub-domínio específico com
suas regras específicas
● Domínio é um processo que nossos clientes executam no dia-a-dia.
● Domínio é o que o cliente faz, é seu negócio.

15. O que é um modelo?

16. O que é um modelo?
● Modelos são uma simplificação da realidade
● Com DDD, o modelo é o código, e o código é o modelo.
● Quadro Branco
● BDD
● TDD

17. Por onde começamos a modelagem com DDD?

18. Linguagem Ubíqua / Linguagem Onipresente
● A Linguagem Ubíqua é uma linguagem compartilhada e desenvolvida pelo
Domain Experts e de pela equipe de desenvolvimento.
● A Linguagem Ubíqua é a linguagem do negócio dentro da empresa e todos
devem fazer uso dela para expressar corretamente todos processos / intenções
de negócio.

19. Linguagem Ubíqua / Linguagem Onipresente
Nos requisitos o cliente usou palavras como:
● Segurado
● Dependente
● CNH
● Apólices podem ter dependentes
● Dependentes podem ser desativados
Tais conceitos de negócio necessitam estar refletidos no modelo e no nosso código,
pois elas fazem parte do domínio que nossos usuários conhecem.

20. Quando não respeitamos a linguagem ubíqua.

21. Modelagem estratégica ou projeto estratégico
● bounded context
● mapa de contextos
● núcleo compartilhado
● camada anti-corrupção

22. Darwin e Mendel

23. Como implementamos o modelo?

24. Modelagem Tática
● Entity (Entidade)
○ Uma entidade do domínio, é uma classe que possui identidade e um ciclo de vida, além de
possuir estados, comportamentos e lógica de negócio (lógica de domínio).
● Value Object
○ Um objeto que agrega valor de negócio as entidades, não possui identidade e deve ser imutável.
● Agregados
○ Compostos de Entidades ou Objetos de Valores que são encapsulados numa única classe. O
Agregado serve para manter a integridade do modelo.

25. Modelagem Tática
● Factory
○ Classe responsável por construir adequadamente uma raiz de agregação e ou entidades. Algumas
vezes, agregados são relativamente complexos e não queremos manter a lógica de criação desses
agregados nas classes que o compõem.
● Repository
○ Uma classe que tem a finalidade de abstrair a persistência do domínio. Ela existe com a finalidade
de facilitar a linguagem ubíqua ao falarmos sobre conceitos de persistência de uma raiz de
agregação / entidade.
● Domain Service
○ Serviço do domínio servem para lógica de negócio que não possuem em “lar”, ou seja, conceitos de
domínio que envolvem N entidades e sua lógica de negócio não é responsabilidade de nenhuma
destas.

26. Como ficaria então a implementação?

27. Juntando tudo teremos algo assim!

28. O domínio ficou rico.

29. Ligando conceitos a implementação!
● Entidade

30. Ligando conceitos a implementação!
● Value Object

31. Ligando conceitos a implementação!
● Agregados

32. Ligando conceitos a implementação!
● pacotes ou namespaces != Módulos

33. Logo DDD tem haver com...
● Entender o negócio do cliente
● O negócio será sempre o centro dos debates
● Colocar o negócio a frente de tecnologias e frameworks, primeiro vamos pensar
em como resolver o problema do cliente
● Integração entre desenvolvedores e especialistas de domínio
● Extrair e entender a linguagem do cliente é de extrema importância para reduzir
o gap de contexto entre os times de desenvolvimento com o cliente
● Entender o contexto de cada domínio para evitar redundância de código /
negócio e modelar as necessidades de determinado contexto

34. E o que não é DDD?

35. O que não é DDD

36. Como aplicar com hexagonal.

37. Erros comuns ao aplicar DDD
● Permitir que a persistência / repositório influencie no modelo de domínio.
● Não se envolver com os especialistas do domínio.
● Ignorar a linguagem ubíqua, ou seja, a linguagem do especialista do domínio.
● Não identificar corretamente os contextos e suas fronteiras.
● Usar um modelo de domínio anêmico.
● Concentrar-se na infraestrutura.
● Achar que DDD é sobre tecnologia.
● Achar que DDD é uma arquitetura em camadas.

38. Quando não usar DDD?

39. Quando não usar DDD
● Sistemas sem muitas regras de negócio, sistemas que são praticamente CRUD.
● Sistemas conversacionais / transacionais.
● Sistemas com domínios instáveis.

40. Benefícios ao utilizar DDD

41. O que DDD tem haver com micro serviços?

42. DDD e micro serviços
● Um micro serviço é um possível bounded context.
● DDD facilita o entendimento, descoberta e modelagem de micro serviços
● Práticas como bounded context nos ajudam a visualizar / descobrir serviços
● A implementação do modelo rico faz com que os micro serviços tornem-se
menos acoplados facilitando a manutenção e evolução do mesmo

43. Por onde começar?

44. Por onde começar?

45. Por onde começar?
● http://www.eduardopires.net.br/2016/08/ddd-nao-e-arquitetura-em-camadas/
● http://www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-design
● https://www.infoq.com/br/news/2016/05/ddd-microservices-evans
● https://www.infoq.com/br/news/2016/01/architecture-ddd-cqrs
● https://www.kenneth-truyers.net/2013/12/05/introduction-to-domain-driven-
design-cqrs-and-event-sourcing/
● http://www.eduardopires.net.br/2016/03/ddd-bounded-context/
● https://martinfowler.com/bliki/BoundedContext.html

46. Implementação
https://github.com/DanielEverling/ProjetoDominioAnemico
https://github.com/DanielEverling/ProjetoOrientadoAoDominio
https://github.com/citerus/dddsample-core
https://github.com/VaughnVernon/IDDD_Samples

47. Dúvidas?