Introdução ao Domain-Driven Design

1.855 visualizações

Publicada em

Publicada em: Tecnologia
0 comentários
3 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.855
No SlideShare
0
A partir de incorporações
0
Número de incorporações
187
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
3
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Introdução ao Domain-Driven Design

  1. 1. André Zanatta Borgonovo
  2. 2. 1. Introdução2. Conceitos3. Arquitetura4. Artefatos de Domínio (exemplos em C#)5. Aplicação e Processo
  3. 3. O que é e não é DDD
  4. 4.  Algo que resolve tudo Sempre a melhor solução Um caminho fácil para seguir “Everything should be made as simple as possible, but not simpler.” Albert Einsten
  5. 5.  Design (Projeto) Orientado ao Domínio Uma abordagem de desenvolvimento de software Uma metodologia de arquitetura para a evolução de um sistema alinhado às necessidades do negócio Software OO feito da maneira correta (Jak Charlton, DDD Step-by-step)
  6. 6. “Atacando as Complexidades no Coração do Software” Eric Evans
  7. 7. 1. Corrige a arquitetura do projeto. Diminui a complexidade e aumenta a manutenibilidade da aplicação2. Você faz software para durar3. Quem deve se preocupar com DDD?4. “Durabilidade” do DDD5. Outros *DDs
  8. 8.  O foco é no domínio, são as regras de negócio, os comportamentos O foco NÃO é trabalhar com o banco de dados Software de negócios com regras complexas “Domínio é a área de conhecimento do software”
  9. 9.  O foco deve ser o domínio e a lógica do domínio Projetos complexos devem ser baseados em um modelo Iniciar uma colaboração criativa entre a área técnica e os domain experts para iterativamente estarem mais perto do coração conceitual do problema
  10. 10. Linguagem ubíqua, contextosdelimitados, módulos, domainexpert, domínio e modelo
  11. 11. Ubiquitous = Ubíquo = Está em todo lugarLinguagem ubíqua é a linguagem usada pelo: Business expert = Domain expert = Product owner (Scrum)• O time inteiro utiliza a mesma linguagem• Não utilizar linguagem técnica para falar com o Domain expert• Proximidade entre o Domain expert e os desenvolvedores• A análise realizada deve ser natural para o Domain expert• É importante que todos do projeto conheçam o domínio • Substantivos = Classes • Verbos = Métodos, Serviços e etc.
  12. 12.  É relativo. Não tem padrão. Baseado em abstrações. É usado para resolver problemas. Tem que ser útil. Deve estar atualizado. Deve refletir no código. Representa o domínio. Use POCOs (Plain Old CLR Objects)
  13. 13. Pode ser assim: Ferramenta ajuda a manter seu modelo atualizado …Ou assim:
  14. 14. ApresentaçãoAplicaçãoDomínioInfraestrutura
  15. 15. • Camadas devem estar separadas• Separação de responsabilidades• Arquitetura flexível Layers X Tiers Layers: Camadas lógicas Tiers: “Projetos do Visual Studio”
  16. 16. Usuário pode ser outro sistema.Camada de apresentação
  17. 17. Coordena as atividades (workflow)da aplicação. Transformação deobjetos (DTOs).Transação, auditoria e segurança.
  18. 18. “A camada de domínio é ocoração do software”
  19. 19. Persistência de dados.Conceitos transversais:autenticação, autorização,cache, gerenciamento deexceções, log, validação.
  20. 20. Usuário pode ser outro sistema.Camada de apresentaçãoCoordena as atividades (workflow)da aplicação. Transformação deobjetos (DTOs). Transação,auditoria e segurança.“A camada de domínio é ocoração do software”Persistência de dados.Conceitos transversais:autenticação, autorização,cache, gerenciamento deexceções, log, validação.
  21. 21. Entidades, objetos de valor,agregações, fábricas, serviçose repositórios
  22. 22.  Objetos que tem significado no Domínio Tem identidade Exemplos: ◦ Cliente ◦ Carro ◦ Produto
  23. 23. Abstração para entidadesEntidade simples
  24. 24.  Não tem identidade para o negócio São reconhecidos pelos seus atributos Atributo diferente = objeto diferente Imutáveis Exemplos: ◦ Cores ◦ Coordenadas ◦ Endereços
  25. 25. Abstração para objetos de valorObjeto de valor simples
  26. 26.  Reúne entidades e objetos de valor que fazem sentido no domínio Raiz da agregação (Aggregate Root) Regras de agregações: ◦ Todas as atualizações passam pela raiz ◦ Todas as referencias obtidas para os objetos recupera-se pela raiz ◦ Exclusão apaga todos os filhos da agregação ◦ Regras de negócio são garantidas pela raiz
  27. 27.  Resolvem problemas de negócio, mas não são entidades ou objetos de valor Um bom serviço tem três caracteristicas: 1. A operação é relacionada a um conceito do domínio que não é naturalmente parte de uma entidade ou objeto de valor 2. A interface é definida baseada em outros objetos do modelo do dominio 3. A operação é Stateless
  28. 28.  Criam objetos de negócio É responsabilidade de um objeto construir a si mesmo? Regras complexas para construção Fábrica cria objetos consistentes
  29. 29.  “Não tem banco de dados” Persistence Ignorance Representam uma lista de itens em memória Não tem lógica de negócio. No máximo valida consistência do objeto. Assim como guardou deve ser recuperado São especificados para Agregações, não para Entidades
  30. 30. Abstração para repositóriosRepositório simples
  31. 31. Exemplo deimplementação derepositório com EntityFramework
  32. 32.  Fábricas criam os objetos Repositórios: ◦ Inserem; ◦ Recuperam; ◦ Alteram; ◦ Destroem os objetos.
  33. 33. Go DDD, go Agile!
  34. 34.  Regras de negócio complexas Atenção: ◦ Arquitetos geralmente trabalham em projetos complexos ◦ Projetos simples podem se tornar importantes para o negócio da empresa no futuroUse DDD na maior parte dos softwares que tem regra de negócio
  35. 35.  Não para o desenvolvimento em cascata (Waterfall). Recomendado desenvolvimento ágil DDD aceita as mudanças. Software se torna altamente adaptável Proximidade e contato com o Domain expert
  36. 36. AutorAndré Zanatta Borgonovoazborgonovo@gmail.com@azborgonovoLinks Recomendadoshttp://domaindrivendesign.org/http://microsoftnlayerapp.codeplex.com/http://blog.lambda3.com.br/

×