O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Introdução ao Domain-Driven Design

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Carregando em…3
×

Confira estes a seguir

1 de 46 Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (14)

Quem viu também gostou (20)

Anúncio

Semelhante a Introdução ao Domain-Driven Design (20)

Mais recentes (20)

Anúncio

Introdução ao Domain-Driven Design

  1. 1. André Zanatta Borgonovo
  2. 2. 1. Introdução 2. Conceitos 3. Arquitetura 4. 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ção 2. Você faz software para durar 3. Quem deve se preocupar com DDD? 4. “Durabilidade” do DDD 5. 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, contextos delimitados, módulos, domain expert, domínio e modelo
  11. 11. Ubiquitous = Ubíquo = Está em todo lugar Linguagem 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ção Aplicação Domínio Infraestrutura
  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 de objetos (DTOs). Transação, auditoria e segurança.
  18. 18. “A camada de domínio é o coração do software”
  19. 19. Persistência de dados. Conceitos transversais: autenticação, autorização, cache, gerenciamento de exceções, log, validação.
  20. 20. Usuário pode ser outro sistema. Camada de apresentação Coordena as atividades (workflow) da aplicação. Transformação de objetos (DTOs). Transação, auditoria e segurança. “A camada de domínio é o coração do software” Persistência de dados. Conceitos transversais: autenticação, autorização, cache, gerenciamento de exceções, log, validação.
  21. 21. Entidades, objetos de valor, agregações, fábricas, serviços e repositórios
  22. 22.  Objetos que tem significado no Domínio  Tem identidade  Exemplos: ◦ Cliente ◦ Carro ◦ Produto
  23. 23. Abstração para entidades Entidade 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 valor Objeto 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órios Repositório simples
  31. 31. Exemplo de implementação de repositório com Entity Framework
  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 futuro Use 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. Autor André Zanatta Borgonovo azborgonovo@gmail.com @azborgonovo Links Recomendados http://domaindrivendesign.org/ http://microsoftnlayerapp.codeplex.com/ http://blog.lambda3.com.br/

×