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

1. Ddd – Domain driven design

2. Domain-Driven Design 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.

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ões Boas práticas Experiência

6. Foco: Domínio Alinhamento com negócio Isolamento entre domínios Reutilização Mínimoacoplamento Independente de tecnologia

7. DDD A voltadaOrientação a Objetos?

8. Padrões no DDD [Contexto] [Discussão do problema] Resumo do problema Discussãodasolução Porestarazão Resumodasolução Consequências, implementação, exemplos. [Contextoresultante]

9. DDD

10. Colocando o modelo de domínioparafuncionar LinguagemUbíqua

11. Model Driven Design Domínio Guia Modelo Design Refatoração Desenvolvedoresperdidos e tecnologiainadequada Sofwarenão serve para o domínio Aperfeiçoa

12. Blocos de Construção doModelDrivenDesign

13. ArquiteturaemCamadas

14. Entidades

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

16. Agregados Entidade Agregado Entidade Objeto de Valor Objeto de Valor

17. Fábricas Quandoconstruir (Agregados) for complexo; Devem ser sempreabstratas; Nãofazem parte do modelo, mas do domínio.

18. Serviços A operaçaonãofaz parte de nenhumaEntidadeouObjeto de Valor; Interface fala a língua do Domínio; Semestado.

19. Módulos Agrupeconceitos do modelo, nãocódigo; Baixoacoplamento / altacoesão; NomesdaLinguagemUbíqua.

20. Módulos Modelo = História Módulo = Capítulo Módulo = Capítulo Módulo = Capítulo Módulo = Capítulo Módulo = Capítulo Módulo = Capítulo

21. Repositórios CódigoCliente Repositório Busca Entidade Entidades Cria Agregados Agregados Entidades Agregados Remover Entidades

22. LinguagemUbíqua Model Driven Design Expressamodelocomo Módulos Serviços Entidades Objetos Valor Acessa com Encapsula com MantémIntegridade com Encapsula com Repositórios Agregados Fábricas Acessa com Encapsula com

23. Refatorandoparacompreenderprofundamente o modelo

24. Padrõespararefinar o modelo Interfaces de intençãorevelada Eufaçoexatamenteisso. Nãoprecisa se preocuparcomo.

25. Padrõespararefinar o modelo Funçõessemefeitoscolaterais Colocartudo o que for possívelemfunções, principalmenteemcálculoscomplexos Ondenãoder, usarcomandosquefazempoucasoperações e nãoretornamobjetos do domínio

26. Padrõespararefinar o modelo Asserções Testes de unidade; Usarfacilidadesdalinguagem; Testam o comportamento dos comandos.

27. LinguagemUbíqua Model Driven Design desenhadas usando Expressamodeloatravés de Interfaces de IntençãoRevelada Torna efeitos colaterais explícitos com Asserções cria seguras e simples FunçõessemEfeitosColaterais Tornacomposiçãosegura

28. ProjetoEstratégico

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

30. ProjetoEstratégico - Padrões Integraçãocontínua Fazerfigurapróximo slide

31. IntegraçãoContínua Novo Elemento do Modelo Codificação Testes automatizados; Processo de build automático; Sincronizaçãodiária; Relatórios.

32. ProjetoEstratégico - Padrões Mapa do Contexto

33. ProjetoEstratégico - Padrões NúcleoCompartilhado É maisdifícilfazermudanças; Evita (masnãoelimina) duplicações.

34. ProjetoEstratégico - Padrões Produtor – Consumidor Testes automatizados Cliente - Fornecedor

35. ProjetoEstratégico - Padrões Conformista Time 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ões Camada Anti-Corrupção

37. ProjetoEstratégico - Padrões Caminhosseparados Quandointegrarcustacaro e o benefício é pequeno; Contextodelimitadoquenão tem nenhumaconexão com osoutros.

38. Resumindo Trabalhando com um modelo; Blocos de construção; Refatorando e evoluindo; Refinando, destilando.

39. Refinando um modelo

40. IssoNão é Tudo

41. DDD 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. 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 DDD Quantomaispróximovocêestá do negócio, menossofre com mudanças O entendimento do desenvolvedorsobre o negócio, evitandoerros e ajudando no negócioemsi, questionando e sugerindootimizações. Códigomenosacoplado e maiscoeso.

43. Conclusão Procure utilizar DDD emaplicações com domínioscomplexos LinguagemUbíqua e MDD são o cerneda DDD Não se apegue à rigidezconceitual, e claro, não lute contra os frameworks.

44. Referências Evans, Eric. Domain Driven Design. Addison – Wesley, 2004. http://www.infoq.com/resource/minibooks/domain-driven-design-quickly/en/pdf/DomainDrivenDesignQuicklyOnline.pdf http://vimeo.com/3545313