O documento discute Domain Driven Design (DDD) como uma abordagem para modelar aplicações em Node.js com foco no domínio de negócio. Ele explica como DDD pode ajudar a incorporar o problema de negócio no software através da criação de um modelo do domínio que guie o projeto e desenvolvimento, sendo enriquecido ao longo do tempo. Também discute a divisão do projeto em diferentes níveis táticos e estratégicos.

1. Domain Driven Design
Como modelar uma aplicação em Node.js com DDD ?

2. Por que DDD?

3. #polêmica

4. SoftwareMundo real

5. SoftwareMundo real
Incerto
Certo

6. SoftwareMundo real
Controlável
Não controlável
Incerto
Certo

7. Como fazer esta
transição?

8. Dificuldades
● Entender o negócio leva tempo
● O modelo mental do problema real geralmente não está bem definido
● Entender o problema a especificar bem leva tempo
Negócio Desenvolvedor

9. Problemas traiçoeiros
Negócios
● Tempo é escasso
● Desenvolvimento de software é
geralmente visto como um "centro de
custo" e não como um de "centro de
lucro"
● O software não satisfaz as
necessidades de negócio
Desenvolvimento
● Tempo é escasso
● A tecnologia é vista como mais
importante que o problema de negócio
● O modelo de software não reflete o
modelo de negócio
● "Big ball of mud"
● Modelos de dados quebrados e/ou "o
que era isso mesmo?"

10. E se incorporamos o
problema no software?

11. Negócio Desenvolvedor

12. Negócio Desenvolvedor

13. Negócio Desenvolvedor

14. Negócio Desenvolvedor

15. Negócio Desenvolvedor

16. Domain Driven Design

17. Design/Projeto dirigido ao domínio
● Domínio: é a área de interesse onde o software será desenvolvido
● Design/projeto: "esquematização"/ implementação dos requisitos no software
Arquitetura
Design / Projeto
Código

18. Domínio Modelo

19. Domínio Modelo

20. Domínio Modelo

21. Domínio ProjetoModelo

22. Design/Projeto dirigido ao domínio
● O modelo irá guiar como o software será projetado / desenvolvido
● O modelo será enriquecido através da aquisição de conhecimento, obtido ao longo do
desenvolvimento do software (linguagem úbiqua)

23. Design/Projeto dirigido ao domínio

24. Design/Projeto dirigido ao domínio
● O modelo irá guiar como o software será projetado / desenvolvido
● O modelo será enriquecido através da aquisição de conhecimento, obtido ao longo do
desenvolvimento do software (linguagem úbiqua)
● A modelagem não deve ser perfeccionista e sim efetiva

25. Domínio ProjetoModelo

26. Domínio ProjetoModelo

27. Domínio ProjetoModelo

28. Domínio Modelo Projeto

29. Domínio Modelo Projeto
Negócio Desenvolvedor
Linguagem
úbiqua

30. Design/Projeto dirigido ao domínio
● O modelo irá guiar como o software será projetado / desenvolvido
● O modelo será enriquecido através da aquisição de conhecimento, obtido ao longo do
desenvolvimento do software (linguagem úbiqua)
● A modelagem não deve ser perfeccionista e sim efetiva
● Projeto pode ser dividido em diferentes níveis:
○ Design/projeto tático

31. Entidades
Value
Objects
Agregados
Agregados
Domain
Services
Modules
Factories

32. Design/Projeto dirigido ao domínio
● O modelo irá guiar como o software será projetado / desenvolvido
● O modelo será enriquecido através da aquisição de conhecimento, obtido ao longo do
desenvolvimento do software (linguagem úbiqua)
● A modelagem não deve ser perfeccionista e sim efetiva
● Projeto pode ser dividido em diferentes níveis:
○ Design/projeto tático ("menor" unidade de software)

33. Design/Projeto dirigido ao domínio
● O modelo irá guiar como o software será projetado / desenvolvido
● O modelo será enriquecido através da aquisição de conhecimento, obtido ao longo do
desenvolvimento do software (linguagem úbiqua)
● A modelagem não deve ser perfeccionista e sim efetiva
● Projeto pode ser dividido em diferentes níveis:
○ Design/projeto tático ("menor" unidade de software)
○ Design/projeto estratégico

35. Design/Projeto dirigido ao domínio
● O modelo irá guiar como o software será projetado / desenvolvido
● O modelo será enriquecido através da aquisição de conhecimento, obtido ao longo do
desenvolvimento do software (linguagem úbiqua)
● A modelagem não deve ser perfeccionista e sim efetiva
● Projeto pode ser dividido em diferentes níveis:
○ Design/projeto tático ("menor" unidade de software)
○ Design/projeto estratégico (diversos softwares / serviços)

36. Let's code?

37. Fonte: http://www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-design

38. Requisito: retrieve tweets
"I need to get a number of tweets with a specific hashtag, discover
the sentiment about the tweets and save for further analysis."

39. Requisito: retrieve tweets
"I need to get a number of tweets with a specific hashtag,
discover the sentiment about the tweets and save for further
analysis."

40. Requisito: retrieve tweets
"I need to get a number of tweets with a specific hashtag,
discover the sentiment about the tweets and save for further
analysis."
● Tweet entity
● Get tweets by hashtag behaviour
● Discover sentiment behaviour
● Save tweet behaviour

41. Obrigado !
danielbpdias@gmail.com
https://github.com/danielbdias/nodebr-meetup-ddd-demo