Apresentação na Semana Acadêmica da UNISOCIESC em 2010 sobre Domain Driven Design, mais conhecido como DDD.

1. Arquitetura e modelagem de Software orientada a domínio
Domain Driven Design
Lorival Smolski Chapuis
MCPD ASP.NET
http://blog.lorival.com / lorival@chapuis.com.br
Centro de Inovação Microsoft
SOCIESC 2010
Sociedade Educacional de Santa Catarina

2. “... 1 hora não dá pra nada. Você vai mostrar a
mecânica do DDD, e o pessoal vai sair achando que
DDD é entidades+repositórios... Já percebi que por
mais esforço que façamos, técnicos tendem a
simplificar o que viram, e sobra só isso na cabeça
deles ...”
Giovani Bassi
Arquiteto de Software, MVP
Considerações iniciais
2

3. • O que é Domain Driven Design
• Surgimento, objetivos e vantagens
• Essência do Domain Driven Design
• Modelando um domínio real
• Regras para modelagem
• Arquitetura em camadas
• Caixa de ferramentas Microsoft
• Apresentação de uma aplicação
• Considerações finais
Agenda
3

4. É uma abordagem de design de software
disciplinada que reúne um conjunto de
conceitos, técnicas e princípios para
construção de softwares baseados em um
modelo de domínio.
Domain Driven Design
4

5. É uma abordagem de design de software
Disciplinada que reúne um conjunto de
conceitos, técnicas e princípios para
construção de softwares baseados em um
modelo de domínio.
Domain Driven Design
5

6. É uma abordagem de design de software
Disciplinada que reúne um conjunto de
conceitos, técnicas e princípios para
construção de softwares baseados em um
modelo de domínio.
Domain Driven Design
6
É todo e qualquer conhecimento (esfera
de conhecimento) utilizado em uma
determinada área.
Um domínio possuí regras de negócio.

7. É uma abordagem de design de software
Disciplinada que reúne um conjunto de
conceitos, técnicas e princípios para
construção de softwares baseados em um
modelo de domínio.
Domain Driven Design
7

8. É uma abordagem de design de software
Disciplinada que reúne um conjunto de
conceitos, técnicas e princípios para
construção de softwares baseados em um
modelo de domínio.
Domain Driven Design
8
Pode ser expresso de várias formas:
apresentação de slides, UML, rascunhos
em papel, organograma, etc...

9. É uma abordagem de design de software
Disciplinada que reúne um conjunto de
conceitos, técnicas e princípios para
construção de softwares baseados em um
modelo de domínio.
Domain Driven Design
9

10. É uma abordagem de design de software
Disciplinada que reúne um conjunto de
conceitos, técnicas e princípios para
construção de softwares baseados em um
modelo de domínio.
Domain Driven Design
10
Object Oriented
programming
Ubiquitous
Language
Domain
patterns
Layered
architecture
Design patterns
...
...

11. Surgimento
11
Há 20 anos criam-se padrões
e técnicas para arquitetura e
modelagem de software
Orientada a Objetos.
Há 6 anos Eric Evans
compilou várias destas
técnicas e unindo com suas
experiências criou o DDD

12. Há 20 anos criam-se padrões
e técnicas para arquitetura e
modelagem de software
Orientada a Objetos.
Há 6 anos Eric Evans
compilou várias destas
técnicas e unindo com suas
experiências criou o DDD
Surgimento
12
Design de
domínio
Pouco foi escrito
sobre isso
Não se tinha
claro como
deveria ser feito

13. Há 20 anos criam-se padrões
e técnicas para arquitetura e
modelagem de software
Orientada a Objetos.
Há 6 anos Eric Evans
compilou várias destas
técnicas e unindo com suas
experiências criou o DDD
Surgimento
13
Padrões de
arquitetura
Mais de 10 anos
como arquiteto
de software
Boas práticas
Padrões de
desenvolvimento
Grandes e
pequenos
projetos

14. 1. Aproximar desenvolvimento
de software do domínio do
problema.
2. Aumentar a vida de um
software.
3. Ter códigos mais claros e
fáceis de entender.
4. Utilizar o principal recurso da
orientação a objetos: a
aproximação do mundo real
através de abstrações.
Objetivos
14

15. Vantagens
15
1. Fácil comunicação entre
desenvolvedores, analistas e
clientes.
2. Construir software testáveis.
3. Fácil manutenção e
crescimento do software.
4. Agregar ou trocar
colaboradores na equipe de
desenvolvimento não é mais
um problema.
5. Entenda o cliente, o modelo e
o código.

16. • Para a maioria dos projetos de software o foco
principal deve ser no domínio
• O modelo deve ser baseado em um domínio
• Você conhece software, o BusinessExpert conhece
o domínio, ouve-o.
• A Ubiquitous Language deve predominar desde o
BusinessExpert até a equipe de desenvolvimento
Essência do Domain Driven Design
16

17. Modelos são baseados em abstrações
17

18. Modelos são baseados em abstrações
18

19. Modelos são baseados em abstrações
19

20. Modelos são baseados em abstrações
20

21. Modelos são baseados em abstrações
21

22. Modelos são baseados em abstrações
22

23. Modelos são baseados em abstrações
23

24. Modelos são baseados em abstrações
24

25. • Objetivo principal: Extrair empresas de sites
Vamos modelar...
25
Empresa: Emp A
Rua A, 001. cep:AA
Cidade: Cidade A, AA
Empresa: Emp B
Rua B, 002. cep: BB
Cidade: Cidade B, BB
Empresa: EmpC
Rua C, 003 . cep: CC
Cidade: Cidade C, CC
Empresa Rua Nº CEP Cidade Estado
Emp A A 001 AA Cidade A AA
Emp B B 002 BB Cidade B BB
Emp C C 003 CC Cidade C CC

26. Atividades atuais
26

27. Regras de modelagem
27

28. • São identificadas através de uma identidade
• Um objeto pode ter uma identidade em um domínio
e não ter em outro
versus
• Se uma entidade mudar a regra de negócio é
afetada
Entidades
28

29. • São identificadas através de suas propriedades
(atributos)
• Um objeto de valor não pode ser alterado, ele é
sempre removido e adicionado um novo
• Não são o foco do negócio
Objetos de valor
29

30. Atividades atuais
30

31. Entidades
31

32. Atividades atuais
32

33. Entidades
33

34. Atividades atuais
34

35. Entidades
35

36. Atividades atuais
36

37. Objetos de valor
37

38. Objetos de valor
38

39. • Reúnem entidades e objetos de valor de modo a
fazer sentido para o negócio.
• Definem fronteiras claras
• Toda agregação tem uma raiz
Agregações
39

40. Agregações
40

41. Agregações
41

42. Agregações e suas raizes
42

43. Agregações e suas raízes
43

44. • Fingem que tem todos os
dados em memória.
• Para o consumidor do
repositório não faz diferença
onde está o objeto.
• São responsáveis por guardar
ou destruir objetos.
Repositórios
44

45. Repositórios
45

46. Modelo incompleto
46

47. • Resolvem problemas de negócio mas não são
entidades nem objetos de valor, pois possuem
apenas comportamentos e não estados de negócio.
Serviços
47

48. Serviços
48

49. • Cria objetos complexos ou que possuam dificuldade
de construir.
• Será responsabilidade de um objeto se construir?
Fábricas
49

50. Fábricas
50

51. Modelo completo
51

52. Arquitetura
52

53. • Mínimo:
– Microsoft Visual Studio 2010 (IDE)
– Microsoft.Net Framework
• Comum:
– Microsoft Entity Framework 4.0 (ORM)
– Microsoft Unity Framework (Inje. Dependência)
– Microsoft Sql-Server 2008
• Recomendado:
– Microsoft Test (Testes automatizados)
– Code Coverage
– Microsoft MVC Framework (web)
Caixa de ferramentas
53

54. Aplicação
54

55. Considerações finais
55

56. Considerações finais
56

57. Domain Driven Design
Dúvidas?
Centro de Inovação Microsoft
SOCIESC 2010
Sociedade Educacional de Santa Catarina
Lorival Smolski Chapuis
MCPD ASP.NET
http://blog.lorival.com / lorival@chapuis.com.br