Programando com prazer com DDD

6.225 visualizações

Publicada em

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

Publicada em: Tecnologia
0 comentários
20 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
6.225
No SlideShare
0
A partir de incorporações
0
Número de incorporações
842
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
20
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

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 />

×