Domain Driven Design - Aplicando conceitos e padrões
•
3 gostaram•1,411 visualizações
Apresentação de conceitos básicos sobre DDD
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (19)
Semelhante a Domain Driven Design - Aplicando conceitos e padrões
Semelhante a Domain Driven Design - Aplicando conceitos e padrões (20)
Domain Driven Design - Aplicando conceitos e padrões
- 1. Domain Driven Design Aplicando Estratégias e Padrões João Paulo Santos, MSc 1
- 2. Formação Mestre em Sistemas de Informação – UNIRIO Linha de pesquisa: Sistemas de Apoio a Negócios Pós-Graduado em Gerenciamento de Projetos – FGV Bacharel em Informática - UERJ Coordenador Pedagógico do MIT em Arquitetura de Software Professor de Graduação e Pós-Graduação Infnet, Decision (FGV-POA), UERJ Experiência de Mercado + de 15 anos com Integração de Sistemas,Arquitetura de Software,Análise e Desenvolvimento de Sistemas Arquiteto de Sistemas focado na definição dos componentes de software e integração das soluções da Gestora de Recursos do Banco do Brasil. Possui mais de 15 anos de experiência atuando nas áreas de Integração de Sistemas,Arquitetura de Software,Análise e Desenvolvimento de Sistemas Domain Driven Design – Aplicando Estratégias e Padrões 2 Quem sou...
- 3. Abordar sucintamente os principais conceitos de Domain Driven Design. Discutir e demonstrar a aplicação de estratégias e padrões na elaboração de um modelo de domínio. Objetivos Domain Driven Design – Aplicando Estratégias e Padrões 3
- 4. Estudantes de graduação e pós-graduação nas áreas de sistemas de software Analistas e desenvolvedores de software Arquitetos de software Publico alvo Domain Driven Design – Aplicando Estratégias e Padrões 4
- 5. Contextualização : modelo, domínio e modelo de domínio Problemas com a orientação a objetos Conceitos básicos de DDD Técnicas para modelagem de domínio Padrões de domínio Agenda Domain Driven Design – Aplicando Estratégias e Padrões 5
- 6. Domain Driven Design – Aplicando Estratégias e Padrões 6 O que é isso?
- 7. É uma simplificação Representa algum aspecto da realidade com uma ideia que seja de interesse Interpretação da realidade que destaca os aspectos relevantes para resolver o problema Ignora os detalhes “estranhos” Domain Driven Design – Aplicando Estratégias e Padrões 7 Modelo
- 8. Área de conhecimento Área de interesse dos usuários Exemplo: Domínios do mundo físico: Programa de reserva de passagens aéreas – pessoas reais entrando em aeronaves reais Domínio intangível: Programa de contabilidade – dinheiro e as finanças Domínio Domain Driven Design – Aplicando Estratégias e Padrões 8
- 9. “Os modelos de domínios podem trazer grandes vantagens para o controle do desenvolvimento de softwares – sejam quais forem a linguagem e o ambiente em que eles sejam implementados” Martin Fowler Domain Driven Design – Aplicando Estratégias e Padrões 9
- 10. Ferramenta para atacar a sobrecarga de informação e complexidade de um domínio É uma forma de abstração rigorosamente organizada e seletiva do conhecimento dos especialistas Dá sentido as informações Concentra-se em um problema Modelo de Domínio Domain Driven Design – Aplicando Estratégias e Padrões 10
- 11. Um diagrama específico Uma questão de se criar um modelo o mais realista possível e sim é uma criação artificial Simplesmente a criação de um mecanismo de software que forneça os resultados necessários Modelo de Domínio Não é Domain Driven Design – Aplicando Estratégias e Padrões 11
- 12. O modelo e o coração do design dão forma um ao outro O modelo é a “espinha dorsal” de uma linguagem utilizada por todos os membros da equipe O modelo é um conhecimento destilado Modelo de Domínio é útil para: Domain Driven Design – Aplicando Estratégias e Padrões 12
- 13. Lembra? Domain Driven Design – Aplicando Estratégias e Padrões 13 1980 1986 1969 - Smaltalk
- 14. Foco em Arquitetura e Design (independente do domínio) Ferramentas e frameworks têm, silenciosamente, deturpado os valores originais da POO Por que a POO não é suficiente? Domain Driven Design – Aplicando Estratégias e Padrões 14 “Falta disciplina para modelagem de domínios grandes e complexos”
- 15. O foco principal para construção de sistemas deveria ser no domínio e na lógica do negócio O design de um domínio complexo deveria ser baseado em um modelo Por que a POO não é suficiente? Domain Driven Design – Aplicando Estratégias e Padrões 15
- 16. Solução... Domain Driven Design – Aplicando Estratégias e Padrões 16
- 17. É um conjunto de técnicas comprovadas de modelagem notadamente para aplicações complexas É um conjunto de princípios e práticas que dão suporte ao processo de desenvolvimento É um conjunto de padrões que formam um visão coesa e coerente do modelo de domínio É um conjunto de estratégias que permitem escalar aplicações em tamanho e complexidade Domain Driven Design Domain Driven Design – Aplicando Estratégias e Padrões 17
- 18. O time e os experts no domínio trabalham de forma contínua (e iterativa) refinando o modelo e buscando melhor compreensão do problema a ser solucionado Os canais de comunicação entre os domain experts e o time devem estar sempre abertos DDD e Colaboração Domain Driven Design – Aplicando Estratégias e Padrões 18
- 19. Modelo e Design devem evoluir em sincronia – desenvolvimento contínuo O código é a última (e mais importante) forma de expressão do modelo Artefatos intermediários servem basicamente como documentos temporários Modelo de Domínio e Design Domain Driven Design – Aplicando Estratégias e Padrões 19
- 20. Domain Driven Design – Aplicando Estratégias e Padrões 20 Como entender o negócio e modelar um domínio corretamente?
- 21. Desenvolvedores Especialista do domínio Foco em classes, métodos, algoritmos, padrões Comparações entre conceitos da vida real e artefatos de programação Criação de classes de objeto e suas relações com o modelo Pensam em termos de encapsulamento, herança e polimorfismo Foco em suas competências específicas Não conhecem sobre desenvolvimento de software e nem técnicas de modelagem Não tem idéia do que é um framework, persistência e em muitos casos nem sobre bancos de dados Domain Driven Design – Aplicando Estratégias e Padrões 21 A necessidade de uma linguagem comum
- 22. Os especialistas do domínio conhecem: Ordem de negócio Ações Stop Loss Pu,Var,Tir, PL Fluxo de Caixa Utilizam um jargão próprio que não é facilmente compreendido pelos membros da equipe técnica A equipe técnica também possui o seu próprio jargão: Query, SQL, SGBD Patterns MaquinaVirtual Exemplo – Mercado Financeiro Domain Driven Design – Aplicando Estratégias e Padrões 22
- 23. A Comunicação é fundamental para o sucesso do projeto Se um diz algo e os outros não entendem, ou pior, entendem em outra conotação, quais são as chances de sucesso deste projeto? Problemas de Comunicação Domain Driven Design – Aplicando Estratégias e Padrões 23
- 24. Precisamos falar a mesma linguagem Domain Driven Design – Aplicando Estratégias e Padrões 24
- 25. Linguagem Ubíqua Conecta-se a todas as partes do design Define premissas e conceitos Leva semanas e até meses para tomar forma em projetos de grande complexidade Os especialistas devem atentar para os termos que transmitam o adequado conhecimento do domínio Desenvolvedores devem atentar para eventuais ambigüidades ou incoerência Domain Driven Design – Aplicando Estratégias e Padrões 25
- 26. Linguagem Ubíqua viabiliza a elaboração do modelo de domínio Profissionais que modelam o domínio também codificam o software Programadores devem se sentir também responsáveis pelo modelo, caso contrário não haverá relação do código com o modelo Processo de maturação contínuo Linguagem Ubíqua – Modelo de Domínio Domain Driven Design – Aplicando Estratégias e Padrões 26
- 27. Resolução dos problemas do domínio é realizada por uma pequena parte do sistema Os elementos do domínio devem ser visto como um sistema Os objetos do domínio devem estar desacoplados do sistema Conceitos do domínio não devem ser confundidos com conceitos relacionados a tecnologia do software Isolando o Domínio Domain Driven Design – Aplicando Estratégias e Padrões 27
- 28. Arquitetura Domain Driven Design Domain Driven Design – Aplicando Estratégias e Padrões 28
- 29. MVC x DDD Domain Driven Design – Aplicando Estratégias e Padrões 29
- 30. Também chamado de padrões Utilizados para representar o Modelo Foco na camada Domínio Os blocos são classificados em: Entidades (Entities) Objeto deValor (Value Objects) Serviços (Services) Blocos de Construção Domain Driven Design – Aplicando Estratégias e Padrões 30
- 31. necessitam de uma identidade fio de continuidade elementos do domínio que possuem ciclo de vida dentro de um sistema Cliente se cadastra faz compras se torna inativo é excluído etc. Entities Domain Driven Design – Aplicando Estratégias e Padrões 31
- 32. Objetos que carregam somente valores não possuem distinção de identidade As instâncias de Objetos deValores são imutáveis, isto é, uma vez criados, seus atributos internos não “deveriam” mais ser modificados. Value Objects Domain Driven Design – Aplicando Estratégias e Padrões 32
- 33. A operação representa um conceito do domínio que não é parte natural de uma Entity ouVO A interface é definida em termos de outros elementos do modelo do domínio É importante ressaltar que Serviços não guardam estado toda chamada a um mesmo serviço, dada uma mesma pré-condição, deve retornar sempre o mesmo resultado Services Domain Driven Design – Aplicando Estratégias e Padrões 33
- 34. • Serviço do aplicativo de transferência de fundos • Digere as entradas (tais como uma solicitação XML) • Envia mensagens para o serviço do domínio para complementação • Espera a confirmação • Decide enviar uma notificação através de um serviço de infra-estrutura Aplicativo • Serviço do domínio de transferência de fundos • Interage com os objetos Conta e Livro Razão necessários, realizando débitos e créditos adequadamente • Fornece a confirmação do resultado (transferência permitida ou não, e assim por diante) Domínio • Serviço de notificação de envio • Envia e-mails, cartas e outros comunicados conforme instruído pelo aplicativo Infra- estrutura Exemplo - Dividindo Serviços em Camadas Adaptado do livro Domain Driven Design, Eric Evans. Domain Driven Design – Aplicando Estratégias e Padrões 34
- 35. Utilização dos três padrões Agregados Fábricas Repositórios Os Agregados demarcam o escopo dentro do qual as invariantes tem que ser mantidas em cada estágio do ciclo de vida As Fábricas e os Repositórios operam sobre os Agregados, encapsulando a complexidade de transições específicas do ciclo de vida Integridade e Complexidade Domain Driven Design – Aplicando Estratégias e Padrões 35 Como manter a integridade do modelo com o crescimento da complexidade?”
- 36. Um Agregado é composto por um grupo associado de Entities eValue Objects Agregados são tratado como uma só unidade para efeitos de persistência Elegemos uma classe para servir de raiz do Agregado As referências são permitidas apenas para a raiz A manipulação dos dados de uma das classes que compõem o Agregado somente poderá ser feita através da classe raiz Agregado Domain Driven Design – Aplicando Estratégias e Padrões 36
- 37. Agregado Domain Driven Design – Aplicando Estratégias e Padrões 37
- 38. Administram o ciclo de vida dos outros objetos Entidades Objetos deValor Agregados Fornecem um mecanismo para encapsular o armazenamento, recuperação e comportamento de busca para obter coleções de objetos. Em linguagens como Java e .NET, repositórios são comumente implementados usando-se frameworks como Hibernate ou Nhibernate Repositório Domain Driven Design – Aplicando Estratégias e Padrões 38
- 39. Repositório Domain Driven Design – Aplicando Estratégias e Padrões 39
- 40. São responsáveis pelo processo de criação dos Agregados ou dos Objetos deValores Agregados podem ser relativamente complexos de se criar e não é desejável manter a lógica de criação destes Agregados nas classes que o compõem As regras de criação são encapsuladas em uma classe externa, a Fábrica Fábrica Domain Driven Design – Aplicando Estratégias e Padrões 40
- 41. Fábrica Domain Driven Design – Aplicando Estratégias e Padrões 41
- 42. Requisitos Corretores registram ofertas Sistema envia email marketing todos os dias pela manhã Sistema seleciona as ofertas do dia Cliente compra oferta Cliente paga oferta Sistema emite cupom ao final do dia Cliente utiliza cupom Parceiro baixa cupom Sistema paga o valor das vendas aos Parceiros Sistema paga comissão aos Corretores Domain Driven Design – Aplicando Estratégias e Padrões 42 Exemplo – Compras Coletivas
- 43. Domain Driven Design – Aplicando Estratégias e Padrões 43 Draft - Compras Coletivas
- 44. DDD - Conclusões Promove alta coesão e baixo acoplamento. Torna fácil testar componentes de negócio. A lógica de negócio do domínio é isolada de non-domain e código de infra- estrutura A adição/mudança de serviços não causa impacto no domínio ou em outros serviços Todos os stakeholders falam uma mesma linguaguem (Ubiquitous Language) Domain Driven Design – Aplicando Estratégias e Padrões 44
- 45. Domain Driven Design – Aplicando Estratégias e Padrões 45 Obrigado!
- 46. EDUCAÇÃO SUPERIOR ORIENTADA AO MERCADO Rua São José 90, 2º andar Esquina com Avenida Rio Branco CEP 20010-020 Domain Driven Design – Aplicando Estratégias e Padrões 46