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

1. DomainDriven Design Programando com prazer com DDD Giovanni Bassi MVP, MCSD, MCPD, CSM

2. Giovanni Bassi Arquiteto de software Consultoria, gestão e mentoring Treinamento Microsoft MostValuable Professional em C# (MVP) InetaBoardMember C#, VB, J#, F#, etc... .Net de Beta a Beta Dezenas de artigos na .Net Magazine Editor técnico da .Net Magazine Palestrante Professor universitário Líder e fundador do .Net Architects

3. Online @: Email: giggio@giggio.net Blog: http://unplugged.giggio.net Site: http://giovannibassi.com Twitter: @giovannibassi

4. Objetivo Entender porque é mais divertido programar com DDD

5. Agenda

7. Visão de futuro ou... Porque o arquiteto deve ser preocupar com DDD

8. Começando pelo começo: o que é DDD? “É uma abordagem para o desenvolvimento de software”

10. Qual o foco do DDD?

11. Focado no banco?

12. Focado no domínio!

13. Motivo 1: Estamos livres do banco de dados! (pelo menos até o final da iteração)

14. Quais são as duas principais premissas do DDD? “Para a maioria dos projetos 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 um modelo.” Eric Evans

15. Domínio? Esfera de conhecimento, influênciaouatividade. A áreaemque o usuárioutiliza o software.

16. Motivo 2: Acabou a briga com o usuário!

17. Modelo? Não...

18. Não precisa ser impecavelmente realista O mundo segundo os chineses do século XVIII

19. Usadopara resolver problemas

20. Modelos são abstrações Isso quer dizer que o que não interessa fica de fora Se você conseguir equalizar isso, o modelo é perfeito Modelos devem refletir o código ou são irrelevantes

21. Não há padrão para um modelo Ele pode ser assim... Ou assim...

22. No modelo vão...

23. Motivo 3: Use o que faz sentido pra você e para sua empresa!

24. UbiquitousLanguage (está em toda parte) Vem dos business experts É refletida no modelo É refletida no código É falada pelo time

25. Não Sim “Carga” “Conta corrente” “Serviço de tradução de itinerário” “Repositório de clientes” “Agendamento de horário” “Tabela” “Classe” “Thread” “Banco de dados” “Façade” “.Net 3.5”

26. Ouça o Business Expert É ele quem conhece o problema, não você

27. Motivo 4: Entenda o cliente! Entenda o resto do time. Entenda o código!

28. Camadas Camadas devem fazer sentido (verifique suas responsabilidades) Se não separou não é camada Layers != Tiers

30. “Esta camada é o coração de um software de negócios” Eric Evans

31. Motivo 5: Livre-se do código macarrônico que mistura responsabilidades

32. Entidades têm significado no domínio Entidades possuem identidade Cores: Azul Amarelo Verde Vermelho Objetos de valor não tem identidade para o negócio Objetos de valor são reconhecidos por seus atributos Objetos de valorfreqüentemente são imutáveis

33. Agregaçõesreunem entidades e objetos de valor de maneira que faça sentido para o negócio Agregações definem fronteirasclaras Toda agregação tem uma raiz

35. Algumas regras...

36. ( ) Utilize: POCOs Plain Old CLR Objects Bom e velhoobjeto do CLR

37. Motivo 6: Classes de negócio de verdade são muito mais fáceis de entender.

38. Serviços resolvem problemas de negócio mas não são entidades nem objetos de valor Serviços não possuem estado de negócio

40. Motivo 7: Resolvido o problema de “onde eu ponho esse método?”

41. Factories criam objetos Levemente diferente das factories de padrões de projeto Objetos devem ser criados consistentes Será responsabilidade de um objeto se construir?

42. Como criar qualquer destes objetos? Só com factories

43. Motivo 8: Defina claramente onde seus objetos nascem. Fim dos problemas de referência circular em entidades.

44. Repositórios fingem que têm todos os dados na memória Para o consumidor do repositório não faz muita diferença onde está o objeto Os Repositórios são os responsáveis por persistir e destruir os objetos

45. publicvoidUpdateCustomer(Customercustomer) { using (var transaction = _session.BeginTransaction()) { try { _session.Update(customer); transaction.Commit(); } catch (NHibernate.HibernateException) { transaction.Rollback(); throw; } } }

46. Algumas regras...

47. Mais regras...

48. Esclarescendo... A idéia do repositório vem do repositorypattern (Fowler, PoEAA) DDD != Repositorypattern

49. Motivo 9: Fim (quase) dos problemas de transação.

50. Motivo 10: Um ponto único para obter e salvar as entidades

51. Ciclo de vida: Factories criam Repositórios recuperam Repositórios alteram Repositórios destroem

52. Motivo 11: Definições claras de come interagir com dados persistentes.

53. Processo

54. Funciona assim?

55. Feedback é fundamental O tempo todo!

56. Assim é bem mais fácil

57. Aceite as mudanças... ... não brigue com elas

58. Motivo 12: DDD + agilidade = (Paz * Produtividade) ^ satisfação do cliente

59. DDD pode dar trabalho Então o foco são projetos com regras de negócio complexas

60. Downloads 

61. Referências DomainLanguage (empresa do Evans)http://domainlanguage.com/ Grupo do Yahoo sobre DDD (eminglês)http://groups.yahoo.com/group/domaindrivendesign Greg Young(MVP - eminglês)http://codebetter.com/blogs/gregyoung/ Domain Driven Design.org (eminglês)http://www.domaindrivendesign.org/ Jimmy Nilsson (eminglês)http://jimmynilsson.com

62. Recomendação de leitura

63. Demonstração

64. Perguntas ?

65. Não se esqueçam de preencher as fichas de avaliação

66. Obrigado! Giovanni Bassi giggio@giggio.net http://giovannibassi.com