DDD - Domain Driven Design

6,379
-1

Published on

Apresentação sobre DDD - Domain Driven Design na pós graduação em Engenharia de Software Centrada em Métodos Ágieis

Published in: Education
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
6,379
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
134
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide

DDD - Domain Driven Design

  1. 1. Ddd – Domain driven design<br />
  2. 2. Domain-Driven Design<br />Domain-DrivenDesign não é uma tecnologia ou metodologia, mas sim uma abordagem de design de software disciplinada que reúne um conjunto de conceitos, técnicas e princípios com foco no domínio e na lógica do domínio para criar um domainmodel.<br />
  3. 3. Domain-Driven Design<br /> O modelopode ser expresso de váriasformas, comoumaapresentaçãoem PowerPoint, diagramasem UML, rascunho de papel, peças de Lego, o mesmo o códigodaaplicação.<br />
  4. 4. Padrões<br /> É umaregra de trêspartesqueexpressa a relação entre um contexto1, um problema² e umasolução³.<br />
  5. 5. O que é DDD?<br />Livro de Eric Evans (2004)<br />Padrões<br />Boas práticas<br />Experiência<br />
  6. 6. Foco: Domínio<br />Alinhamento com negócio<br />Isolamento entre domínios<br />Reutilização<br />Mínimoacoplamento<br />Independente de tecnologia<br />
  7. 7. DDD<br />A voltadaOrientação a Objetos?<br />
  8. 8. Padrões no DDD<br />[Contexto]<br />[Discussão do problema]<br />Resumo do problema<br />Discussãodasolução<br />Porestarazão<br />Resumodasolução<br />Consequências, implementação, exemplos.<br />[Contextoresultante]<br />
  9. 9. DDD<br />
  10. 10. Colocando o modelo de domínioparafuncionar<br />LinguagemUbíqua<br />
  11. 11. Model Driven Design<br />Domínio<br />Guia<br />Modelo<br />Design<br />Refatoração<br />Desenvolvedoresperdidos e tecnologiainadequada<br />Sofwarenão serve para o domínio<br />Aperfeiçoa<br />
  12. 12. Blocos de Construção doModelDrivenDesign<br />
  13. 13. ArquiteturaemCamadas<br />
  14. 14. Entidades<br />
  15. 15. Objetos de Valores<br />Praquemnãoprecisa de identidade;<br />Imutáveis;<br />Descrevemcoisas;<br />Ciclo de vidarápido;<br />Exemplos: strings, números, cores.<br />
  16. 16. Agregados<br />Entidade<br />Agregado<br />Entidade<br />Objeto de Valor<br />Objeto de Valor<br />
  17. 17. Fábricas<br />Quandoconstruir (Agregados) for complexo;<br />Devem ser sempreabstratas;<br />Nãofazem parte do modelo, mas do domínio.<br />
  18. 18. Serviços<br />A operaçaonãofaz parte de nenhumaEntidadeouObjeto de Valor;<br />Interface fala a língua do Domínio;<br />Semestado.<br />
  19. 19. Módulos<br />Agrupeconceitos do modelo, nãocódigo;<br />Baixoacoplamento / altacoesão;<br />NomesdaLinguagemUbíqua.<br />
  20. 20. Módulos<br />Modelo = História<br />Módulo = Capítulo<br />Módulo = Capítulo<br />Módulo = Capítulo<br />Módulo = Capítulo<br />Módulo = Capítulo<br />Módulo = Capítulo<br />
  21. 21. Repositórios<br />CódigoCliente<br />Repositório<br />Busca<br />Entidade<br />Entidades<br />Cria<br />Agregados<br />Agregados<br />Entidades<br />Agregados<br />Remover<br />Entidades<br />
  22. 22. LinguagemUbíqua<br />Model Driven Design<br />Expressamodelocomo<br />Módulos<br />Serviços<br />Entidades<br />Objetos<br />Valor<br />Acessa com<br />Encapsula com<br />MantémIntegridade com<br />Encapsula com<br />Repositórios<br />Agregados<br />Fábricas<br />Acessa com<br />Encapsula com<br />
  23. 23. Refatorandoparacompreenderprofundamente o modelo<br />
  24. 24. Padrõespararefinar o modelo<br />Interfaces de intençãorevelada<br />Eufaçoexatamenteisso. Nãoprecisa se preocuparcomo.<br />
  25. 25. Padrõespararefinar o modelo<br />Funçõessemefeitoscolaterais<br />Colocartudo o que for possívelemfunções, principalmenteemcálculoscomplexos<br />Ondenãoder, usarcomandosquefazempoucasoperações e nãoretornamobjetos do domínio<br />
  26. 26. Padrõespararefinar o modelo<br />Asserções<br />Testes de unidade;<br />Usarfacilidadesdalinguagem;<br />Testam o comportamento dos comandos.<br />
  27. 27. LinguagemUbíqua<br />Model Driven Design<br />desenhadas<br />usando<br />Expressamodeloatravés de<br />Interfaces de IntençãoRevelada<br />Torna efeitos<br />colaterais<br />explícitos com<br />Asserções<br />cria seguras<br />e simples<br />FunçõessemEfeitosColaterais<br />Tornacomposiçãosegura<br />
  28. 28. ProjetoEstratégico<br />
  29. 29. ProjetoEstratégico - Padrões<br />ContextoDelimitado<br /> As célulasexistemporquesuamembrana define o queestádentrooufora e determina o quepodeentrar.<br />
  30. 30. ProjetoEstratégico - Padrões<br />Integraçãocontínua<br />Fazerfigurapróximo slide<br />
  31. 31. IntegraçãoContínua<br />Novo Elemento do Modelo<br />Codificação<br />Testes automatizados;<br />Processo de build automático;<br />Sincronizaçãodiária;<br />Relatórios.<br />
  32. 32. ProjetoEstratégico - Padrões<br />Mapa do Contexto<br />
  33. 33. ProjetoEstratégico - Padrões<br />NúcleoCompartilhado<br />É maisdifícilfazermudanças;<br />Evita (masnãoelimina) duplicações.<br />
  34. 34. ProjetoEstratégico - Padrões<br />Produtor – Consumidor<br />Testes automatizados<br />Cliente - Fornecedor<br />
  35. 35. ProjetoEstratégico - Padrões<br />Conformista<br />Time fornecedornãointeresseemajudar;<br />Tiracomplexidade de tradução entre contextos;<br />Mesmalinguagemubíqua;<br />Parecido com NúcleoCompartilhado , masclientenão tem poder de modificação.<br />
  36. 36. ProjetoEstratégico - Padrões<br />Camada Anti-Corrupção<br />
  37. 37. ProjetoEstratégico - Padrões<br />Caminhosseparados<br />Quandointegrarcustacaro e o benefício é pequeno;<br />Contextodelimitadoquenão tem nenhumaconexão com osoutros.<br />
  38. 38. Resumindo<br />Trabalhando com um modelo;<br />Blocos de construção;<br />Refatorando e evoluindo;<br />Refinando, destilando.<br />
  39. 39. Refinando um modelo<br />
  40. 40. IssoNão é Tudo<br />
  41. 41. DDD<br />Os padrõescitadossãoapenasalguns dos descritosem Domain Driven Design. DDD é uma forma de desenvolver software que, porestarligado a boas práticas de Orientação a Objetos, tem muito a ver com desenvolvimentoágil. <br />A própriaidéia de Padrões, quepromoveeficácianacomunicação, é um dos valorespregadospelosagilistas. <br />São técnicasquelevarãoaodesenvolvimento de serviços de qualidade, sistemasseguros e fáceis de darmanutenção, levando, consequentemente, à satisfação dos seusclientes com a rapidezque o mercado de hojeexige.<br />
  42. 42. Vantagens de adotar o DDD<br />Quantomaispróximovocêestá do negócio, menossofre com mudanças<br />O entendimento do desenvolvedorsobre o negócio, evitandoerros e ajudando no negócioemsi, questionando e sugerindootimizações.<br />Códigomenosacoplado e maiscoeso.<br />
  43. 43. Conclusão<br />Procure utilizar DDD emaplicações com domínioscomplexos<br />LinguagemUbíqua e MDD são o cerneda DDD<br />Não se apegue à rigidezconceitual, e claro, não lute contra os frameworks.<br />
  44. 44. Referências<br />Evans, Eric. Domain Driven Design. Addison – Wesley, 2004.<br />http://www.infoq.com/resource/minibooks/domain-driven-design-quickly/en/pdf/DomainDrivenDesignQuicklyOnline.pdf<br />http://vimeo.com/3545313<br />

×