Domain Driven Design (DDD) é uma abordagem de design de software focada na lógica e no domínio, que utiliza uma linguagem ubíqua e modelos de domínio para criar soluções eficazes. DDD enfatiza boas práticas como baixo acoplamento, modularização e refatoração para atender a domínios complexos, facilitando a comunicação e a manutenção do código. A adoção do DDD resulta em sistemas mais coesos, alinhados ao negócio e adaptáveis a mudanças.

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

13. ArquiteturaemCamadas

14. Entidades

15. Objetos de ValoresPraquemnãoprecisa de identidade;Imutáveis;Descrevemcoisas;Ciclo de vidarápido;Exemplos: strings, números, cores.

16. AgregadosEntidadeAgregadoEntidadeObjeto de ValorObjeto de Valor

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

21. RepositóriosCódigoClienteRepositórioBuscaEntidadeEntidadesCriaAgregadosAgregadosEntidadesAgregadosRemoverEntidades

22. LinguagemUbíquaModel Driven DesignExpressamodelocomoMódulosServiçosEntidadesObjetosValorAcessa comEncapsula comMantémIntegridade comEncapsula comRepositóriosAgregadosFábricasAcessa comEncapsula com

23. Refatorandoparacompreenderprofundamente o modelo

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

28. ProjetoEstratégico

29. ProjetoEstratégico - PadrõesContextoDelimitado As célulasexistemporquesuamembrana define o queestádentrooufora e determina o quepodeentrar.

30. ProjetoEstratégico - PadrõesIntegraçãocontínuaFazerfigurapróximo slide

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.

39. Refinando um modelo

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