DDD - Domain Driven Design

2,058 views
1,998 views

Published on

DDD - Domain Driven Design - Eric Evans - apresentação feita no IME-USP - Instituto de Matemática e Estatística

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,058
On SlideShare
0
From Embeds
0
Number of Embeds
20
Actions
Shares
0
Downloads
28
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

DDD - Domain Driven Design

  1. 1. Uma introdução a Domain Driven Design Daniel Cukier danicuki@ime.usp.br IME-USPquinta-feira, 26 de fevereiro de 2009
  2. 2. Padrões Um padrão é uma regra de três partes que expressa a relação entre um certo contexto1, um problema 2 e uma solução 3 2quinta-feira, 26 de fevereiro de 2009
  3. 3. O que é DDD ✦ Livro de Eric Evans (2004) ✦ Padrões ✦ Boas práticas ✦ Experiência 3quinta-feira, 26 de fevereiro de 2009
  4. 4. Foco: Domínio ✦ Alinhamento com negócio ✦ Isolamento entre domínios ✦ Reutilização ✦ Mínimo acoplamento ✦ Independente de tecnologia 4quinta-feira, 26 de fevereiro de 2009
  5. 5. DDD A volta da Orientação a Objetos? 5quinta-feira, 26 de fevereiro de 2009
  6. 6. Padrões no DDD [Contexto.] [Discussão do problema.] Resumo do problema. Discussão da solução. Por esta razão: Resumo da solução. Conseqüências, implementação, exemplos. [Contexto resultante.]6quinta-feira, 26 de fevereiro de 2009
  7. 7. DDD Colocando o Blocos de modelo de construção do domínio para MDD funcionar Refatorando para compreender Projeto profundamente o estratégico modelo 7quinta-feira, 26 de fevereiro de 2009
  8. 8. Colocando o modelo de domínio para funcionarquinta-feira, 26 de fevereiro de 2009
  9. 9. Linguagem Ubíqua 9quinta-feira, 26 de fevereiro de 2009
  10. 10. Model Driven Design Domínio guia Modelo Refatoração Design Desenvolvedores Software não serve perdidos e tecnologia para o domínio inadequada aperfeiçoa 10quinta-feira, 26 de fevereiro de 2009
  11. 11. Blocos de Construção do Model Driven Designquinta-feira, 26 de fevereiro de 2009
  12. 12. Arquitetura em Camadas Interface de Usuário Aplicação Domínio DDD Infra-estrutura 12quinta-feira, 26 de fevereiro de 2009
  13. 13. Entidades 13quinta-feira, 26 de fevereiro de 2009
  14. 14. Objetos de Valores ✦ Pra quem não precisa de identidade ✦ Imutáveis ✦ Descrevem coisas ✦ Ciclo de vida rápido ✦ Exemplos: Strings, números, cores 14quinta-feira, 26 de fevereiro de 2009
  15. 15. Agregados Interface Entidade Agregado Objeto de Objeto de Entidade Valor Valorquinta-feira, 26 de fevereiro de 2009
  16. 16. Fábricas ✦ Quando construir (Agregados) for complexo ✦ Devem ser sempre abstratas ✦ Não fazem parte do modelo, mas do domínio 16quinta-feira, 26 de fevereiro de 2009
  17. 17. Serviços 1. A operação não faz parte de nenhuma Entidade ou Objeto de Valor 2. Interface fala a língua do Domínio 3. Sem estado 17quinta-feira, 26 de fevereiro de 2009
  18. 18. Módulos ✦ Agrupe conceitos do modelo, não código ✦ Baixo acoplamento / alta coesão ✦ Nomes da Linguagem Ubíqua 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 18quinta-feira, 26 de fevereiro de 2009
  19. 19. Repositórios Código b usca Cliente Repositório cria Entidade Agregados Agregados Agregados Agregados Agregados Entidades mo ve Entidades Entidades re Entidades Entidades Entidades 19quinta-feira, 26 de fevereiro de 2009
  20. 20. Linguagem Model Ubíqua Driven Design exp ress am ode nomes da lo c omo Módulos Serviços Objetos Entidades acess o com Valor antémde enc m sula integrida Repositórios ap comsul ncapm e co com m la a co psu ac ca es en ocs om Fábricas encapsula com Agregados 20quinta-feira, 26 de fevereiro de 2009
  21. 21. Refatorando para compreender profundamente o modeloquinta-feira, 26 de fevereiro de 2009
  22. 22. Interfaces de Intenção Revelada Eu faço exatamente isso. Não precisa se preocupar como 22quinta-feira, 26 de fevereiro de 2009
  23. 23. Funções sem Efeitos Colaterais ✦ Colocar tudo que for possível em funções, principalmente em cálculos complexos ✦ Onde não der, usar Comandos que fazem poucas operações e não retornam objetos do domínio 23quinta-feira, 26 de fevereiro de 2009
  24. 24. Asserções ✦ Testes de unidade ✦ Usar facilidades da linguagem ✦ Testam o comportamento dos Comandos 24quinta-feira, 26 de fevereiro de 2009
  25. 25. Linguagem Model Driven Design Ubíqua dese expressa n usanhadas modelo do através de Interfaces de Intenção Revelada torna efeitos cria seguras colaterais e simples explícitos com Funções sem Efeitos Asserções Colaterais torna composição seguraquinta-feira, 26 de fevereiro de 2009
  26. 26. Projeto Estratégico 26quinta-feira, 26 de fevereiro de 2009
  27. 27. Contexto Delimitado As células existem porque sua membrana define o que está dentro ou fora e determina o que pode entrar 27quinta-feira, 26 de fevereiro de 2009
  28. 28. Integração Contínua Testes codificação Novo Elemento do Modelo Implementação ✦ Testes automatizados ✦ Processo de build automático ✦ Sincronização diária ✦ Relatórios 28quinta-feira, 26 de fevereiro de 2009
  29. 29. Mapa do Contexto Modelo no Mapa de Contexto Modelo no Tradução Contexto 29quinta-feira, 26 de fevereiro de 2009
  30. 30. Núcleo Compartilhado Compartilhado Mapa de Tradução ✦ É mais difícil fazer mudanças ✦ Evita (mas não elimina) duplicações 30quinta-feira, 26 de fevereiro de 2009
  31. 31. Produtor-Consumidor ✦ Testes automatizados ✦ Cliente-Fornecedor 31quinta-feira, 26 de fevereiro de 2009
  32. 32. Conformista ✦ Time fornecedor não tem interesse em ajudar ✦ Tira complexidade de tradução entre contextos ✦ Mesma linguagem ubíqua ✦ Parecido com Núcleo Compartilhado, mas cliente não tem poder de modificação 32quinta-feira, 26 de fevereiro de 2009
  33. 33. Camada Anti-corrupção Seu sistema Camada Anti-corrupção Outro Sistema Classe Serviço Adaptador Interface elegante A A complicada Outras coisas Tradutor 1 Coisas bem feitas irrelevantes Fachada Classe Classe cara Tradutor 2 bagunçada Ok, isso a Serviço Adaptador Você nem gente tem que B B quer saber refatorar 33quinta-feira, 26 de fevereiro de 2009
  34. 34. Caminhos Separados ✦ Quando integrar custa caro e o benefício é pequeno ✦ Contexto delimitado que não tem nenhuma conexão com os outros 34quinta-feira, 26 de fevereiro de 2009
  35. 35. Resumindo 1. Trabalhando com um modelo 2. Blocos de construção 3. Refatorando e evoluindo 4. Refinando, destilando 35quinta-feira, 26 de fevereiro de 2009
  36. 36. quinta-feira, 26 de fevereiro de 2009
  37. 37. Núcleo Serviço de Linguagem Contexto Integração Conformista Compar- Hospedagem Publicada Delimitado Contínua tilhado Aberto Camada Interfaces de Model Contornos Linguagem Arquitetura Mapa do Anti- Intenção Driven Conceituais Ubíqua em Camadas Contexto corrupção Revelada Design Fechamento Funções sem Caminhos Núcleo Núcleo Objetos de de Efeitos Entidades Separados Abstrato Segregado Valores Isso não é tudo Operações Colaterais Classes Subdomínios Núcleo do Mecanismos Asserções Serviços Módulos Isoladas Genéricos Domínio Coesivos Nível de Sentença da Ordem Núcleo Conheci- Visão do Agregados Fábricas que Evolui Destacado mento Domínio Arcabouço Camadas de Metáfora Componente Responsa- Repositórios de Sistema Plugável bilidadequinta-feira, 26 de fevereiro de 2009
  38. 38. Referências ✦Evans, Eric - Domain Driven Design, Addison- Wesley - 2004 ✦http://www.infoq.com/resource/minibooks/ domain-driven-design-quickly/en/pdf/ DomainDrivenDesignQuicklyOnline.pdf 38quinta-feira, 26 de fevereiro de 2009

×