Introdução ao Domain-Driven Design
4 gostaram2,278 visualizações
O documento apresenta os conceitos e arquitetura do Design Orientado a Domínio (DDD). Ele explica que DDD é uma abordagem de desenvolvimento de software focada nas regras de negócio e no domínio, não nos bancos de dados. O documento também descreve artefatos como entidades, objetos de valor, agregações, serviços e repositórios.
Introdução ao Domain-Driven Design
- 2. 1. Introdução 2. Conceitos 3. Arquitetura 4. Artefatos de Domínio (exemplos em C#) 5. Aplicação e Processo
- 3. O que é e não é DDD
- 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. 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. “Atacando as Complexidades no Coração do Software” Eric Evans
- 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. 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. 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. Linguagem ubíqua, contextos delimitados, módulos, domain expert, domínio e modelo
- 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. É 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. Pode ser assim: Ferramenta ajuda a manter seu modelo atualizado …Ou assim:
- 15. • Camadas devem estar separadas • Separação de responsabilidades • Arquitetura flexível Layers X Tiers Layers: Camadas lógicas Tiers: “Projetos do Visual Studio”
- 17. Usuário pode ser outro sistema. Camada de apresentação
- 18. Coordena as atividades (workflow) da aplicação. Transformação de objetos (DTOs). Transação, auditoria e segurança.
- 19. “A camada de domínio é o coração do software”
- 20. Persistência de dados. Conceitos transversais: autenticação, autorização, cache, gerenciamento de exceções, log, validação.
- 21. 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.
- 23. Entidades, objetos de valor, agregações, fábricas, serviços e repositórios
- 24. Objetos que tem significado no Domínio Tem identidade Exemplos: ◦ Cliente ◦ Carro ◦ Produto
- 25. Abstração para entidades Entidade simples
- 26. 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
- 27. Abstração para objetos de valor Objeto de valor simples
- 30. 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
- 33. 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
- 35. Criam objetos de negócio É responsabilidade de um objeto construir a si mesmo? Regras complexas para construção Fábrica cria objetos consistentes
- 37. “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
- 38. Abstração para repositórios Repositório simples
- 39. Exemplo de implementação de repositório com Entity Framework
- 40. Fábricas criam os objetos Repositórios: ◦ Inserem; ◦ Recuperam; ◦ Alteram; ◦ Destroem os objetos.
- 41. Go DDD, go Agile!
- 42. 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
- 43. 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
- 46. Autor André Zanatta Borgonovo [email protected] @azborgonovo Links Recomendados http://domaindrivendesign.org/ http://microsoftnlayerapp.codeplex.com/ http://blog.lambda3.com.br/