Domain-Driven-Design

667 views
589 views

Published on

Uma apresentação sobre Domain Driven Design

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
667
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
8
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Domain-Driven-Design

  1. 1. Domain Driven Design (DDD)Wende Mendes HiginoEmail: wende.mendes@bluesoft.com.br
  2. 2. Objetivo O que o DDD pode fazer por você
  3. 3. Visão de futuroPorque os arquitetos desoftware devem sepreocupar com o DDD ?Temos que fazer softwarepara durar
  4. 4. O que é DDD ?“ É uma abordagem para desenvolvimento de software ”
  5. 5. Qual é o foco do DDD ?
  6. 6. Banco de dados ?
  7. 7. Focado no domínio
  8. 8. Principais premissas do (DDD) “ Para a maioria dosprojetos de software o foco principal deve ser no domínio e na lógica do domínio ”“ Desenhos complexos de domínio devem ser baseados em modelos ”
  9. 9. Domínio ?
  10. 10. Domínio: - Área de conhecimento do software Exemplo: domínio do software de uma farmácia: - controle de preço, estoque, etc.
  11. 11. Modelo ?
  12. 12. O mundo
  13. 13. O mundo Não precisa ser impecavelmente realista
  14. 14. Modelos ? - Modelo são baseados em abstrações. - É uma idéia e deixa um monte de detalhes defora.
  15. 15. O mundo Excesso de informações atrapalha
  16. 16. Brasil
  17. 17. São Paulo
  18. 18. BlueSoft
  19. 19. BlueSoft Usado para resolver problemas
  20. 20. Recapitulando: * Modelos são abstrações - O que não interessa fica de fora - O modelo deve refletir no código ou são irrelevantes - O modelo deve representar o seu domínio
  21. 21. Não há padrão para um modelo
  22. 22. Pode ser assim:
  23. 23. Ou assim:
  24. 24. Compõe o modelo...
  25. 25. Ubiquitous Language: - Vem dos business experts - É refletida no modelo - É refletida no código - É falada pelo time
  26. 26. Não Sim- Tabela - Carga- Classe - Conta corrente- método - Agendamento de horários- String - Deposito bancário- Banco de dados - Realizar matricula
  27. 27. Ouça business expertsÉ ele que entende do negócio.É ele que conhece o problema, nãovocê
  28. 28. Distância dos desenvolvedores e o contexto do domínio
  29. 29. - Camadas devem fazer sentido.“ verifique suas responsabilidades ”- As camadas tem que ter separação
  30. 30. Camadas do DDD
  31. 31. "Esta camada é o coração de um software de negócio” (Eric Evans)
  32. 32. Conceitos do DDD
  33. 33. Entidade: São objetos que tem significado no domínioEntidade: possuem identidades
  34. 34. Objetos de Valor- Objetos de valor não tem identidade para o negócio- São reconhecidos por seus atributos- Geralmente são imutáveis Exemplo: Azul Verde Vermelho
  35. 35. Agregações - Reúnem entidades e objetos de valor de maneira que faça sentido para o negócio - Toda agregação tem uma raiz
  36. 36. Algumas regras:
  37. 37. Serviços- Serviços resolvem problemas de negócio, masnão são entidades e nem objetos de valor- Se meu serviço precisar retornar algumobjeto, este objeto tem que estar no meudomínio
  38. 38. ServiçosExemplo :
  39. 39. Factories- Criam objetos- Objetos devem ser criados consistentes
  40. 40. FactoriesExemplo :
  41. 41. Repositórios- Responsáveis por persistir e destruir os objetos- Responsáveis por guardar e recuperar objetos- Falar a língua do negócio* Vai ter métodos: - obter por data - obter por cpf - obter por vencimento
  42. 42. Exemplo de um projeto
  43. 43. Exemplo de um projeto
  44. 44. Camadas do domínio
  45. 45. Camadas do domínio
  46. 46. Camadas do domínio
  47. 47. Ciclo de vida de umobjeto para o DDD:- Factories criam objetos
  48. 48. Ciclo de vida de umobjeto para o DDD: - Factories criam objetos - Repositórios recuperam objetos
  49. 49. Ciclo de vida de umobjeto para o DDD: - Factories criam objetos - Repositórios recuperam objetos - Repositórios alteram objetos
  50. 50. Ciclo de vida de um objeto para o DDD:- Factories criam objetos- Repositórios recuperam objetos- Repositórios alteram objetos- Repositórios destroem objetos
  51. 51. Ciclo de vida:- Factories criam objetos- Repositórios recuperam objetos- Repositórios alteram objetos- Repositórios destroem objetos
  52. 52. Funciona assim ?
  53. 53. Funciona assim ?
  54. 54. Feedback é fundamental.O tempo todo !
  55. 55. Recomendação
  56. 56. - O DDD aceita mudanças- Não brigue com elas
  57. 57. Recomendações: “ O foco são os projetos com regras de negócio complexas ” “ Quando as empresas fam que o projeto é simples, comece a tomar cuidado, pois eles crescem ” “ Comece com projetos pequenos para aprender ”
  58. 58. Obrigado
  59. 59. Bibliografia

×