Baixado 38 vezes
Carregado porLorival Smolski Chapuis
Domain driven design - Visão Geral
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.
Mais conteúdo relacionado
Semelhante a Domain driven design - Visão Geral
Domain driven design - Visão Geral
- 1. Arquitetura e modelagemde Software orientada a domínio Domain Driven Design Lorival Smolski Chapuis MCPD ASP.NET http://blog.lorival.com / lorival@chapuis.com.br Centro de Inovação Microsoft SOCIESC 2010 Sociedade Educacional de Santa Catarina
- 2. “... 1 horanã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 abordagemde 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 abordagemde 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 abordagemde 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 abordagemde 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 abordagemde 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 abordagemde 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 abordagemde 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 anoscriam-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 anoscriam-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 anoscriam-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 desoftware 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çãoentre 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 amaioria 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 baseadosem abstrações 17
- 18. Modelos são baseadosem abstrações 18
- 19. Modelos são baseadosem abstrações 19
- 20. Modelos são baseadosem abstrações 20
- 21. Modelos são baseadosem abstrações 21
- 22. Modelos são baseadosem abstrações 22
- 23. Modelos são baseadosem abstrações 23
- 24. Modelos são baseadosem 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
- 26.
- 27.
- 28. • São identificadasatravé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 identificadasatravé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
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39. • Reúnem entidadese 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.
- 41.
- 42. Agregações e suasraizes 42
- 43. Agregações e suasraízes 43
- 44. • Fingem quetem 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.
- 46.
- 47. • Resolvem problemasde 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.
- 49. • Cria objetoscomplexos ou que possuam dificuldade de construir. • Será responsabilidade de um objeto se construir? Fábricas 49
- 50.
- 51.
- 52.
- 53. • Mínimo: – MicrosoftVisual 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.
- 55.
- 56.
- 57. Domain Driven Design Dúvidas? Centrode Inovação Microsoft SOCIESC 2010 Sociedade Educacional de Santa Catarina Lorival Smolski Chapuis MCPD ASP.NET http://blog.lorival.com / lorival@chapuis.com.br