Introdução a DDD - Palestra .NetRaptors 100loop apresentada para unibh

1. D D D
Introdução ao
@CharlesFortes
.com

2. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
O que é
Domain-DrivenDesign?

3. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
É Desenvolver Focado no
Domínio

4. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
É Desenvolver Focado no
Domínio
WTF?

5. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
Domínio Segundo o Dicionário:
• Esfera de Ação; Competência;
Conhecimento.
• O conteúdo de uma área de
conhecimento.

6. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
Domínio é a área de conhecimento do negócio.
Tudo do Software ligado ao negócio
faz parte do domínio

7. Locadora
Locadora
Locadora
Locadora
Locadora
Locadora
Domain-Driven Design
Introdução ao
@CharlesFortes
.com
Meu Negócio:
Locar Filmes
Fornecedor
Mídias
Filmes
Usuários
Funcionários
Dependentes
Cliente
Locação
de Filme
Reserva
de Filme
...
Cadastros de
Clientes e
Dependentes

8. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
NÃOfaz parte do domínio
Banco de Dadosou Frameworks para os mesmos como o
Nhibernate
Threads
Tratamentos de Excessão

9. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
Principais Vantagens
As tecnologias mudam muito mais rápido do que o negócio
Camadas bem definidas
Responsabilidades claras e bem divididas
Manutenabilidade, Longevidade, Escalabilidade, etc...

10. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
Principais Desvantagens
Mais tempo para desenvolver (porém poupa tempo
futuro durante a manutenção e a extensão)
Complexidade! Não é a solução para todos os problemas...

11. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
O Modelo e a Linguagem Ubíqua
Para o entendimento do domínio deve-se gerar um
MODELO do domínio

12. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
O Modelo e a Linguagem Ubíqua
MODELO
WTF? ?

13. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
O Modelo e a Linguagem Ubíqua
Os modelos são abstrações que visam refletir o código
Evans cita em seu livro que o modelo não pode ser "gordo" demais ao ponto de
prejudicar a compreensão do domínio.

14. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
O Modelo e a Linguagem Ubíqua
E o código, por sua vez, deve ser usado para detalhar o modelo.
Regras importantes devem estar expostas no modelo, e jamais escondidas no
código.

15. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
O Modelo e a Linguagem Ubíqua
O modelo deve ser muito claro!
Deve ser entendido absolutamente da mesma forma por qualquer
pessoa, seja ele
o usuário, o desenvolvedor, o arquiteto, o projetista, o
designer
a menina do marketing, a tia do café, etc

16. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
O Modelo e a Linguagem Ubíqua
Para que o modelo seja entendido é necessário uma
linguagem ubíqua!

17. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
O Modelo e a Linguagem Ubíqua
Para que o modelo seja entendido é necessário uma
linguagem ubíqua!
WTF?

18. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
O Modelo e a Linguagem Ubíqua
Uma linguagem ubíqua é uma linguagem única falada por todos os
envolvidos no projeto, de forma que a todo momento possa-se conversar sobre o projeto
sem ter de ficar traduzindo o que está sendo falado

19. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
O Modelo e a Linguagem Ubíqua
Tudo isso para evitar maus
entendidos

20. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
O Modelo e a Linguagem Ubíqua
O modelo pode ser qualquer coisa, contanto que consiga expressar de forma clara o
domínio

21. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
Todo o domínio
(implementação) giram em torno
do modelo

22. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
Lets Model
0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0
0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0
0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0
0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0
0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0
0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0
0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0
0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0
0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0
0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0
0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0
0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0
0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0
0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0
0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0
0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0
0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0
0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0

23. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
os Serviços Fabricas Entidades Objetos de Valor Repositórios ServiçosFabricas Entidades Objet

24. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
Entidades são objetos que têm significado no domínio, possuindo uma
identidade única
Entidades
UsuárioFilme
Funcionário
Mídia
Dependente
Cliente

25. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
os Serviços Fabricas Entidades Objetos de Valor Repositórios Serviços Fabricas Entidades

26. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
Objetos de Valor não tem valor direto ao negócio, e por isto
não possuem uma identidade.
Cliente
Nome
CPF
Telefone
Endereco
Usados como estrutura de
dados apenas para armazenar
valores.
Muito usados para
transporte de dados ou
composição de
objetos.
Logradouro
Numero
Bairro
etc
etc

27. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
os Serviços Fabricas Entidades Objetos de Valor Repositórios ServiçosFabricas Entidades Objet

28. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
Repositóriossão responsáveis por persistir, recuperar e destruir
objetos
Fingem possuir todas as entidades na memória, para
quem utiliza não importa onde estão os
dados

29. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
Armários de Caixas
Fingem possuir todas as entidades na memória, para
quem utiliza não importa onde estão os
dados
(Sim, foi feito no paint...)

30. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
os Serviços Fabricas Entidades Objetos de Valor Repositórios ServiçosFabricas Entidades Objet

31. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
Serviços na visão do DDD consiste em um objeto que visa resolver
problemas do domínio
Para isto o “service” utiliza
Entidades, Objetos de
Valor, Repositórios,
infraestrutura, etc..

32. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
Meu Negócio:
Locar Filmes
Locar
Filme
Reservar
Filme
Cadastrar
Cliente
Pesquisar
Filme
Etc...
Serviços na visão do DDD consiste em um objeto que visa resolver
problemas do domínio

33. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
os Serviços Fabricas Entidades Objetos de Valor Repositórios ServiçosFabricas Entid

34. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
Muitas vezes criar um novo objeto para atender a um aspecto do
domínio envolve a instanciação de diversas entidades, agregações e
composições.
Quando isto se faz necessário não o fazemos dentro do
construtor da classe, passamos esta responsabilidade para
uma fábrica.
Outras vezes pode ser necessário decidir entre valores de
inicialização padrão ou mesmo da especialização da classe.

35. Domain-Driven Design
Introdução ao
@CharlesFortes
.com

36. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
Neste caso a especialização na construção é prática pois:
• As entidades são mapeadas em diferentes tabelas do banco de dados
• As entidades possuem diferentes validadores

37. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
Lets Code
0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0
0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0
0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0
0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0
0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0
0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0
0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0
0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0
0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0
0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0
0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0
0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0
0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0
0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0
0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0
0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0
0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0
0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0

38. Domain-Driven Design
Introdução ao
@CharlesFortes
.com
Concluindo...
Defina uma linguagem única, expresse o negócio do cliente de forma clara e
certifique-se que TODOS falam a mesma língua.
Implemente de forma que o código traduza de forma analítica o que está foi
modelado, para que daqui a 20 anos, quando o estagiário for mexer no fonte,
ele saiba do que se trata, e se não souber, pode consultar ao productOwner
sem problemas.
E lembre-se do princípio de fazer simples, refatorar e melhorar sempre.

39. Domain-Driven Design
Introdução ao
@CharlesFortes
pangeanet.org/profile/charlesfortes
br.linkedin.com/in/charlesfortes