Domain-Driven Design (DDD) é uma abordagem para desenvolvimento de software focada no domínio do negócio e na lógica de negócio. DDD torna a programação mais divertida ao libertar os desenvolvedores da dependência do banco de dados, focar no entendimento do cliente e separar claramente as responsabilidades do código. Classes de negócio como entidades, agregações, serviços e repositórios ajudam a definir um modelo coerente e compreensível do domínio.

1. DomainDriven DesignProgramando com prazer com DDDGiovanni BassiMVP, MCSD, MCPD, CSM

2. Giovanni BassiArquiteto de softwareConsultoria, gestão e mentoringTreinamentoMicrosoft MostValuable Professional em C# (MVP)InetaBoardMemberC#, VB, J#, F#, etc....Net de Beta a BetaDezenas de artigos na .Net MagazineEditor técnico da .Net MagazinePalestranteProfessor universitárioLíder e fundador do .Net Architects

3. Online @:Email: giggio@giggio.net Blog: http://unplugged.giggio.netSite: http://giovannibassi.comTwitter: @giovannibassi

4. ObjetivoEntender porque é mais divertido programar com DDD

5. Agenda

7. Visão de futuroou... 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 realistaO mundo segundo os chineses do século XVIII

19. Usadopara resolver problemas

20. Modelos são abstraçõesIsso quer dizer que o que não interessa fica de foraSe você conseguir equalizar isso, o modelo é perfeitoModelos devem refletir o código ou são irrelevantes

21. Não há padrão para um modeloEle 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ãoSim“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. CamadasCamadas devem fazer sentido (verifique suas responsabilidades)Se não separou não é camadaLayers != 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ínioEntidades possuem identidadeCores:AzulAmareloVerdeVermelhoObjetos de valor não tem identidade para o negócioObjetos de valor são reconhecidos por seus atributosObjetos de valorfreqüentemente são imutáveis

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

35. Algumas regras...

36. ()Utilize:POCOsPlain Old CLR ObjectsBom 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 valorServiços não possuem estado de negócio

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

41. Factories criam objetosLevemente diferente das factories de padrões de projetoObjetos devem ser criados consistentesSerá 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óriaPara o consumidor do repositório não faz muita diferença onde está o objetoOs 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 criamRepositórios recuperamRepositórios alteramRepositórios destroem

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

53. Processo

54. Funciona assim?

55. Feedback é fundamentalO 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 trabalhoEntão o foco são projetos com regras de negócio complexas

60. Downloads

61. ReferênciasDomainLanguage (empresa do Evans)http://domainlanguage.com/Grupo do Yahoo sobre DDD (eminglês)http://groups.yahoo.com/group/domaindrivendesignGreg 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 Bassigiggio@giggio.nethttp://giovannibassi.com