![Padrões no DDD[Contexto][Discussão do problema]Resumo do problemaDiscussãodasoluçãoPorestarazãoResumodasoluçãoConsequências, implementação, exemplos.[Contextoresultante]](https://image.slidesharecdn.com/ddd-100906095714-phpapp01/85/DDD-Domain-Driven-Design-8-320.jpg)
DDD - Domain Driven Design
- 1. Ddd – Domain driven design
- 2. Domain-Driven DesignDomain-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.
- 3. Domain-Driven Design 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.
- 4. Padrões É umaregra de trêspartesqueexpressa a relação entre um contexto1, um problema² e umasolução³.
- 5. O que é DDD?Livro de Eric Evans (2004)PadrõesBoas práticasExperiência
- 6. Foco: DomínioAlinhamento com negócioIsolamento entre domíniosReutilizaçãoMínimoacoplamentoIndependente de tecnologia
- 7. DDDA voltadaOrientação a Objetos?
- 8. Padrões no DDD[Contexto][Discussão do problema]Resumo do problemaDiscussãodasoluçãoPorestarazãoResumodasoluçãoConsequências, implementação, exemplos.[Contextoresultante]
- 9. DDD
- 10. Colocando o modelo de domínioparafuncionarLinguagemUbíqua
- 11. Model Driven DesignDomínioGuiaModeloDesignRefatoraçãoDesenvolvedoresperdidos e tecnologiainadequadaSofwarenão serve para o domínioAperfeiçoa
- 12. Blocos de Construção doModelDrivenDesign
- 14. Entidades
- 15. Objetos de ValoresPraquemnãoprecisa de identidade;Imutáveis;Descrevemcoisas;Ciclo de vidarápido;Exemplos: strings, números, cores.
- 17. FábricasQuandoconstruir (Agregados) for complexo;Devem ser sempreabstratas;Nãofazem parte do modelo, mas do domínio.
- 18. ServiçosA operaçaonãofaz parte de nenhumaEntidadeouObjeto de Valor;Interface fala a língua do Domínio;Semestado.
- 19. MódulosAgrupeconceitos do modelo, nãocódigo;Baixoacoplamento / altacoesão;NomesdaLinguagemUbíqua.
- 20. MódulosModelo = HistóriaMódulo = CapítuloMódulo = CapítuloMódulo = CapítuloMódulo = CapítuloMódulo = CapítuloMódulo = Capítulo
- 22. LinguagemUbíquaModel Driven DesignExpressamodelocomoMódulosServiçosEntidadesObjetosValorAcessa comEncapsula comMantémIntegridade comEncapsula comRepositóriosAgregadosFábricasAcessa comEncapsula com
- 24. Padrõespararefinar o modeloInterfaces de intençãoreveladaEufaçoexatamenteisso. Nãoprecisa se preocuparcomo.
- 25. Padrõespararefinar o modeloFunçõessemefeitoscolateraisColocartudo o que for possívelemfunções, principalmenteemcálculoscomplexosOndenãoder, usarcomandosquefazempoucasoperações e nãoretornamobjetos do domínio
- 26. Padrõespararefinar o modeloAsserçõesTestes de unidade;Usarfacilidadesdalinguagem;Testam o comportamento dos comandos.
- 27. LinguagemUbíquaModel Driven DesigndesenhadasusandoExpressamodeloatravés deInterfaces de IntençãoReveladaTorna efeitoscolateraisexplícitos comAsserçõescria segurase simplesFunçõessemEfeitosColateraisTornacomposiçãosegura
- 29. ProjetoEstratégico - PadrõesContextoDelimitado As célulasexistemporquesuamembrana define o queestádentrooufora e determina o quepodeentrar.
- 31. IntegraçãoContínuaNovo Elemento do ModeloCodificaçãoTestes automatizados;Processo de build automático;Sincronizaçãodiária;Relatórios.
- 32. ProjetoEstratégico - PadrõesMapa do Contexto
- 33. ProjetoEstratégico - PadrõesNúcleoCompartilhadoÉ maisdifícilfazermudanças;Evita (masnãoelimina) duplicações.
- 34. ProjetoEstratégico - PadrõesProdutor – ConsumidorTestes automatizadosCliente - Fornecedor
- 35. ProjetoEstratégico - PadrõesConformistaTime fornecedornãointeresseemajudar;Tiracomplexidade de tradução entre contextos;Mesmalinguagemubíqua;Parecido com NúcleoCompartilhado , masclientenão tem poder de modificação.
- 36. ProjetoEstratégico - PadrõesCamada Anti-Corrupção
- 37. ProjetoEstratégico - PadrõesCaminhosseparadosQuandointegrarcustacaro e o benefício é pequeno;Contextodelimitadoquenão tem nenhumaconexão com osoutros.
- 38. ResumindoTrabalhando com um modelo;Blocos de construção;Refatorando e evoluindo;Refinando, destilando.
- 40. IssoNão é Tudo
- 41. DDDOs 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. A própriaidéia de Padrões, quepromoveeficácianacomunicação, é um dos valorespregadospelosagilistas. 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.
- 42. Vantagens de adotar o DDDQuantomaispróximovocêestá do negócio, menossofre com mudançasO entendimento do desenvolvedorsobre o negócio, evitandoerros e ajudando no negócioemsi, questionando e sugerindootimizações.Códigomenosacoplado e maiscoeso.
- 43. ConclusãoProcure utilizar DDD emaplicações com domínioscomplexosLinguagemUbíqua e MDD são o cerneda DDDNão se apegue à rigidezconceitual, e claro, não lute contra os frameworks.
- 44. ReferênciasEvans, Eric. Domain Driven Design. Addison – Wesley, 2004.http://www.infoq.com/resource/minibooks/domain-driven-design-quickly/en/pdf/DomainDrivenDesignQuicklyOnline.pdfhttp://vimeo.com/3545313