Domain driven design - Visão Geral
Transferir como PPTX, PDF•2 gostaram•1,152 visualizações
O documento apresenta uma visão geral sobre Domain Driven Design (DDD), destacando sua essência, objetivos e vantagens como abordagem de design de software. Discute a importância de modelar o domínio real e a comunicação entre desenvolvedores e stakeholders, além de detalhar conceitos como entidades, objetos de valor, agregações e repositórios. Também menciona as ferramentas recomendadas para implementação de DDD.
Domain driven design - Visão Geral
- 1. Arquitetura e modelagem de Software orientada a domínio Domain Driven Design Lorival Smolski Chapuis MCPD ASP.NET http://blog.lorival.com / [email protected] Centro de Inovação Microsoft SOCIESC 2010 Sociedade Educacional de Santa Catarina
- 2. “... 1 hora não dá pra nada. Você vai mostrar a mecânica do DDD, e o pessoal vai sair achando que DDD é entidades+repositórios... Já percebi que por mais esforço que façamos, técnicos tendem a simplificar o que viram, e sobra só isso na cabeça deles ...” Giovani Bassi Arquiteto de Software, MVP Considerações iniciais 2
- 3. • O que é Domain Driven Design • Surgimento, objetivos e vantagens • Essência do Domain Driven Design • Modelando um domínio real • Regras para modelagem • Arquitetura em camadas • Caixa de ferramentas Microsoft • Apresentação de uma aplicação • Considerações finais Agenda 3
- 4. É uma abordagem de design de software disciplinada que reúne um conjunto de conceitos, técnicas e princípios para construção de softwares baseados em um modelo de domínio. Domain Driven Design 4
- 5. É uma abordagem de design de software Disciplinada que reúne um conjunto de conceitos, técnicas e princípios para construção de softwares baseados em um modelo de domínio. Domain Driven Design 5
- 6. É uma abordagem de design de software Disciplinada que reúne um conjunto de conceitos, técnicas e princípios para construção de softwares baseados em um modelo de domínio. Domain Driven Design 6 É todo e qualquer conhecimento (esfera de conhecimento) utilizado em uma determinada área. Um domínio possuí regras de negócio.
- 7. É uma abordagem de design de software Disciplinada que reúne um conjunto de conceitos, técnicas e princípios para construção de softwares baseados em um modelo de domínio. Domain Driven Design 7
- 8. É uma abordagem de design de software Disciplinada que reúne um conjunto de conceitos, técnicas e princípios para construção de softwares baseados em um modelo de domínio. Domain Driven Design 8 Pode ser expresso de várias formas: apresentação de slides, UML, rascunhos em papel, organograma, etc...
- 9. É uma abordagem de design de software Disciplinada que reúne um conjunto de conceitos, técnicas e princípios para construção de softwares baseados em um modelo de domínio. Domain Driven Design 9
- 10. É uma abordagem de design de software Disciplinada que reúne um conjunto de conceitos, técnicas e princípios para construção de softwares baseados em um modelo de domínio. Domain Driven Design 10 Object Oriented programming Ubiquitous Language Domain patterns Layered architecture Design patterns ... ...
- 11. Surgimento 11 Há 20 anos criam-se padrões e técnicas para arquitetura e modelagem de software Orientada a Objetos. Há 6 anos Eric Evans compilou várias destas técnicas e unindo com suas experiências criou o DDD
- 12. Há 20 anos criam-se padrões e técnicas para arquitetura e modelagem de software Orientada a Objetos. Há 6 anos Eric Evans compilou várias destas técnicas e unindo com suas experiências criou o DDD Surgimento 12 Design de domínio Pouco foi escrito sobre isso Não se tinha claro como deveria ser feito
- 13. Há 20 anos criam-se padrões e técnicas para arquitetura e modelagem de software Orientada a Objetos. Há 6 anos Eric Evans compilou várias destas técnicas e unindo com suas experiências criou o DDD Surgimento 13 Padrões de arquitetura Mais de 10 anos como arquiteto de software Boas práticas Padrões de desenvolvimento Grandes e pequenos projetos
- 14. 1. Aproximar desenvolvimento de software do domínio do problema. 2. Aumentar a vida de um software. 3. Ter códigos mais claros e fáceis de entender. 4. Utilizar o principal recurso da orientação a objetos: a aproximação do mundo real através de abstrações. Objetivos 14
- 15. Vantagens 15 1. Fácil comunicação entre desenvolvedores, analistas e clientes. 2. Construir software testáveis. 3. Fácil manutenção e crescimento do software. 4. Agregar ou trocar colaboradores na equipe de desenvolvimento não é mais um problema. 5. Entenda o cliente, o modelo e o código.
- 16. • Para a maioria dos projetos de software o foco principal deve ser no domínio • O modelo deve ser baseado em um domínio • Você conhece software, o BusinessExpert conhece o domínio, ouve-o. • A Ubiquitous Language deve predominar desde o BusinessExpert até a equipe de desenvolvimento Essência do Domain Driven Design 16
- 17. Modelos são baseados em abstrações 17
- 18. Modelos são baseados em abstrações 18
- 19. Modelos são baseados em abstrações 19
- 20. Modelos são baseados em abstrações 20
- 21. Modelos são baseados em abstrações 21
- 22. Modelos são baseados em abstrações 22
- 23. Modelos são baseados em abstrações 23
- 24. Modelos são baseados em abstrações 24
- 25. • Objetivo principal: Extrair empresas de sites Vamos modelar... 25 Empresa: Emp A Rua A, 001. cep:AA Cidade: Cidade A, AA Empresa: Emp B Rua B, 002. cep: BB Cidade: Cidade B, BB Empresa: EmpC Rua C, 003 . cep: CC Cidade: Cidade C, CC Empresa Rua Nº CEP Cidade Estado Emp A A 001 AA Cidade A AA Emp B B 002 BB Cidade B BB Emp C C 003 CC Cidade C CC
- 28. • São identificadas através de uma identidade • Um objeto pode ter uma identidade em um domínio e não ter em outro versus • Se uma entidade mudar a regra de negócio é afetada Entidades 28
- 29. • São identificadas através de suas propriedades (atributos) • Um objeto de valor não pode ser alterado, ele é sempre removido e adicionado um novo • Não são o foco do negócio Objetos de valor 29
- 31. Entidades 31
- 33. Entidades 33
- 35. Entidades 35
- 39. • Reúnem entidades e objetos de valor de modo a fazer sentido para o negócio. • Definem fronteiras claras • Toda agregação tem uma raiz Agregações 39
- 40. Agregações 40
- 41. Agregações 41
- 42. Agregações e suas raizes 42
- 43. Agregações e suas raízes 43
- 44. • Fingem que tem todos os dados em memória. • Para o consumidor do repositório não faz diferença onde está o objeto. • São responsáveis por guardar ou destruir objetos. Repositórios 44
- 45. Repositórios 45
- 47. • Resolvem problemas de negócio mas não são entidades nem objetos de valor, pois possuem apenas comportamentos e não estados de negócio. Serviços 47
- 48. Serviços 48
- 49. • Cria objetos complexos ou que possuam dificuldade de construir. • Será responsabilidade de um objeto se construir? Fábricas 49
- 50. Fábricas 50
- 52. Arquitetura 52
- 53. • Mínimo: – Microsoft Visual Studio 2010 (IDE) – Microsoft.Net Framework • Comum: – Microsoft Entity Framework 4.0 (ORM) – Microsoft Unity Framework (Inje. Dependência) – Microsoft Sql-Server 2008 • Recomendado: – Microsoft Test (Testes automatizados) – Code Coverage – Microsoft MVC Framework (web) Caixa de ferramentas 53
- 54. Aplicação 54
- 57. Domain Driven Design Dúvidas? Centro de Inovação Microsoft SOCIESC 2010 Sociedade Educacional de Santa Catarina Lorival Smolski Chapuis MCPD ASP.NET http://blog.lorival.com / [email protected]