O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Programando com prazer com DDD

6.292 visualizações

Publicada em

Palestra apresentada no .Net Architects Day 2009 (dnad2009), em 27 de junho de 2009.

Publicada em: Tecnologia
  • Seja o primeiro a comentar

Programando com prazer com DDD

  1. 1. DomainDriven Design<br />Programando com prazer com DDD<br />Giovanni Bassi<br />MVP, MCSD, MCPD, CSM<br />
  2. 2. Giovanni Bassi<br />Arquiteto de software<br />Consultoria, gestão e mentoring<br />Treinamento<br />Microsoft MostValuable Professional em C# (MVP)<br />InetaBoardMember<br />C#, VB, J#, F#, etc...<br />.Net de Beta a Beta<br />Dezenas de artigos na .Net Magazine<br />Editor técnico da .Net Magazine<br />Palestrante<br />Professor universitário<br />Líder e fundador do .Net Architects<br />
  3. 3. Online @:<br />Email: giggio@giggio.net <br />Blog: http://unplugged.giggio.net<br />Site: http://giovannibassi.com<br />Twitter: @giovannibassi<br />
  4. 4. Objetivo<br />Entender porque é mais divertido programar com DDD<br />
  5. 5. Agenda<br />
  6. 6.
  7. 7. Visão de futuro<br />ou... <br />Porque o arquiteto deve ser preocupar com DDD<br />
  8. 8. Começando pelo começo: o que é DDD?<br />“É uma abordagem para o desenvolvimento de software”<br />
  9. 9.
  10. 10. Qual o foco do DDD?<br />
  11. 11. Focado no banco?<br />
  12. 12. Focado no domínio!<br />
  13. 13. Motivo 1:<br />Estamos livres do banco de dados!<br />(pelo menos até o final da iteração)<br />
  14. 14. Quais são as duas principais premissas do DDD?<br />“Para a maioria dos projetos de software o foco principal deve ser no domínio e na lógica do domínio.”<br />“Desenhos complexos de domínio devem ser baseados em um modelo.”<br />Eric Evans<br />
  15. 15. Domínio?<br />Esfera de conhecimento, influênciaouatividade.<br />A áreaemque o usuárioutiliza o software.<br />
  16. 16. Motivo 2:<br />Acabou a briga com o usuário!<br />
  17. 17. Modelo?<br />Não...<br />
  18. 18. Não precisa ser impecavelmente realista<br />O mundo segundo os chineses do século XVIII<br />
  19. 19. Usadopara resolver problemas<br />
  20. 20. Modelos são abstrações<br />Isso quer dizer que o que não interessa fica de fora<br />Se você conseguir equalizar isso, o modelo é perfeito<br />Modelos devem refletir o código ou são irrelevantes<br />
  21. 21. Não há padrão para um modelo<br />Ele pode ser assim...<br />Ou assim...<br />
  22. 22. No modelo vão...<br />
  23. 23. Motivo 3:<br />Use o que faz sentido pra você e para sua empresa!<br />
  24. 24. UbiquitousLanguage<br />(está em toda parte)<br />Vem dos business experts<br />É refletida no modelo<br />É refletida no código<br />É falada pelo time<br />
  25. 25. Não<br />Sim<br />“Carga”<br />“Conta corrente”<br />“Serviço de tradução de itinerário”<br />“Repositório de clientes”<br />“Agendamento de horário”<br />“Tabela”<br />“Classe”<br />“Thread”<br />“Banco de dados”<br />“Façade”<br />“.Net 3.5”<br />
  26. 26. Ouça o Business Expert<br />É ele quem conhece o problema, <br />não você<br />
  27. 27. Motivo 4:<br />Entenda o cliente!<br />Entenda o resto do time.<br />Entenda o código!<br />
  28. 28. Camadas<br />Camadas devem fazer sentido (verifique suas responsabilidades)<br />Se não separou não é camada<br />Layers != Tiers<br />
  29. 29.
  30. 30. “Esta camada é o coração de um software de negócios”<br />Eric Evans<br />
  31. 31. Motivo 5:<br />Livre-se do código macarrônico que mistura responsabilidades<br />
  32. 32. Entidades têm significado no domínio<br />Entidades possuem identidade<br />Cores:<br />Azul<br />Amarelo<br />Verde<br />Vermelho<br />Objetos de valor não tem identidade para o negócio<br />Objetos de valor são reconhecidos por seus atributos<br />Objetos de valorfreqüentemente são imutáveis<br />
  33. 33. Agregaçõesreunem entidades e objetos de valor de maneira que faça sentido para o negócio<br />Agregações definem fronteirasclaras<br />Toda agregação tem uma raiz<br />
  34. 34.
  35. 35. Algumas regras...<br />
  36. 36. (<br />)<br />Utilize:<br />POCOs<br />Plain Old CLR Objects<br />Bom e velhoobjeto do CLR<br />
  37. 37. Motivo 6:<br />Classes de negócio de verdade são muito mais fáceis de entender.<br />
  38. 38. Serviços resolvem problemas de negócio mas não são entidades nem objetos de valor<br />Serviços não possuem estado de negócio<br />
  39. 39.
  40. 40. Motivo 7:<br />Resolvido o problema de “onde eu ponho esse método?”<br />
  41. 41. Factories criam objetos<br />Levemente diferente das factories de padrões de projeto<br />Objetos devem ser criados consistentes<br />Será responsabilidade de um objeto se construir?<br />
  42. 42. Como criar qualquer destes objetos?<br />Só com factories<br />
  43. 43. Motivo 8:<br />Defina claramente onde seus objetos nascem.<br />Fim dos problemas de referência circular em entidades.<br />
  44. 44. Repositórios fingem que têm todos os dados na memória<br />Para o consumidor do repositório não faz muita diferença onde está o objeto<br />Os Repositórios são os responsáveis por persistir e destruir os objetos<br />
  45. 45. publicvoidUpdateCustomer(Customercustomer)<br /> {<br />using (var transaction = _session.BeginTransaction())<br /> {<br />try<br /> {<br /> _session.Update(customer);<br />transaction.Commit();<br /> }<br />catch (NHibernate.HibernateException)<br /> {<br />transaction.Rollback();<br />throw;<br /> }<br /> }<br /> }<br />
  46. 46. Algumas regras...<br />
  47. 47. Mais regras...<br />
  48. 48. Esclarescendo...<br />A idéia do repositório vem do repositorypattern (Fowler, PoEAA)<br />DDD != Repositorypattern<br />
  49. 49. Motivo 9:<br />Fim (quase) dos problemas de transação.<br />
  50. 50. Motivo 10:<br />Um ponto único para obter e salvar as entidades<br />
  51. 51. Ciclo de vida:<br />Factories criam<br />Repositórios recuperam<br />Repositórios alteram<br />Repositórios destroem<br />
  52. 52. Motivo 11:<br />Definições claras de come interagir com dados persistentes.<br />
  53. 53. Processo<br />
  54. 54. Funciona assim?<br />
  55. 55. Feedback é fundamental<br />O tempo todo!<br />
  56. 56. Assim é bem mais fácil<br />
  57. 57. Aceite as mudanças...<br />... não brigue com elas<br />
  58. 58. Motivo 12:<br />DDD + agilidade =<br />(Paz * Produtividade) ^ satisfação do cliente<br />
  59. 59. DDD pode dar trabalho<br />Então o foco são projetos com regras de negócio complexas<br />
  60. 60. Downloads<br /><br />
  61. 61. Referências<br />DomainLanguage (empresa do Evans)http://domainlanguage.com/<br />Grupo do Yahoo sobre DDD (eminglês)http://groups.yahoo.com/group/domaindrivendesign<br />Greg Young(MVP - eminglês)http://codebetter.com/blogs/gregyoung/<br />Domain Driven Design.org (eminglês)http://www.domaindrivendesign.org/<br />Jimmy Nilsson (eminglês)http://jimmynilsson.com<br />
  62. 62. Recomendação de leitura<br />
  63. 63. Demonstração<br />
  64. 64. Perguntas<br />?<br />
  65. 65. Não se esqueçam de preencher as fichas de avaliação<br />
  66. 66. Obrigado!<br />Giovanni Bassi<br />giggio@giggio.net<br />http://giovannibassi.com<br />

×