Introdução a Domain-Driven Design
Transferir como PPTX, PDF0 gostou501 visualizações
Este documento discute os principais conceitos do Domain-Driven Design (DDD), incluindo: 1) DDD é focado na redução da complexidade de software através da compreensão do domínio do negócio e da criação de modelos expressivos. 2) Os subdomínios são decompostos e os contextos delimitados mapeiam como cada parte será implementada tecnicamente. 3) Os modelos de domínio representam a lógica e regras de negócio de cada subdomínio.
Introdução a Domain-Driven Design
- 1. Domain-Driven Design Leandro A. Vieira Maicon C. Pereira
- 4. Complexidade no Software Essencial Complexidade da Lógica do Negócio/Domínio Acidental Complexidade da Solução Técnica + Código Legado
- 6. Big Ball Of Mud – Grande Bola de Lama • A arquitetura não é bem definida • Correções e pequenas evoluções tornam-se um grande desafio devido a dificuldade de entender o código • Evans: “BBoM é aquele código faz alguma coisa útil, mas sem explicar como”
- 7. “DDD é sobre a redução de complexidade no software” Eric Evans
- 8. DDD é sobre o negócio
- 9. Domínio do Negócio (Domain) • Uma esfera de conhecimento • O que ela faz e como ela faz... • Cada empresa • tem o know-how do segmento/problema que ela atende • E o seu jeito de fazer • Conhecer o domínio é a parte mais importante do DDD
- 10. Exemplo de Domínio • Se você estiver criando um software para gerenciar avaliações de desempenho dos funcionários, você precisará compreender • como as avaliações realmente funcionam, • todo o fluxo de trabalho, • as necessidades e expectativas dos clientes, • como isso afeta a folha de pagamento, etc.,
- 11. DDD é sobre criar modelos altamente expressivos
- 12. O que é um Modelo? • Simplificação da realidade • Mostra alguns aspectos da realidade ou uma ideia de interesse
- 13. Como você representa seu modelo?
- 14. Como você representa seu modelo? User Stories (Text) ?
- 15. Como você representa seu modelo?
- 16. Como você representa seu modelo?
- 17. Modelo é uma representação mental Todo o resto são apenas ferramentas de comunicação
- 18. Como construir um modelo no DDD ?
- 19. Logo... • Domain expert acessível; • Alta interação entre o domain expert e o time de desenvolvimento; Manifesto Ágil • Indivíduos e interações mais que processos e ferramentas • Colaboração com o cliente mais que negociação de contratos • Princípio: Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto. http://www.manifestoagil.com.br
- 20. Linguagem Ubíqua Baseado em uma linguagem comum Expresso em todos os níveis
- 22. #SQN
- 23. Tática sem estratégia é o ruído antes da derrota. Sun Tzu Arte da Guerra
- 24. • Antes de colocar a mão na massa e falar sobre codificação, você deve entender o Problema • O DDD enfatiza • Suas terminologias (LU) • A razão pela qual está sendo desenvolvido • Quais são os fatores de sucesso para o negócio • A necessidade de a equipe de desenvolvimento valorizar o conhecimento do domínio, tanto quanto a experiência técnica
- 26. Problema Domínio VendoLivros S/A Loja de Livros A VendoLivros S/A é uma empresa que comercializa apenas livros, seu grande diferencial está na entrega, que é bem mais rápida que seus concorrentes devido a sua grande expertise em logística e distribuição.
- 28. Lei de Conway Presidência Vendas .. Marketing .. Pagamentos Estoque Entrega ... Resumo: A forma como as organizações estão estruturadas tem um forte impacto sobre os sistemas que elas criam "Qualquer empresa que projeta um sistema (definição mais ampla aqui do que apenas sistemas de informação), inevitavelmente produz um projeto cuja estrutura é uma cópia da estrutura de comunicação da organização.“ Melvin Conway (1968)
- 29. Decompondo o problema Subdomínio Estoque RH, Financeiro Tesouraria ... Vendas Marketing Entrega Domínio VendoLivros Catálogo Pedidos Preços Localização Armazenamento Taxa de entrega Prazo de entrega Parceiros de transporte Propaganda Promoções Pagamentos Boleto Cartão de Crédito Presidên cia ndas .. Marketi ng .. Pagame ntos Estoque Entrega ...
- 30. Decompondo o problema Subdomínio Estoque RH, Financeiro Tesouraria ... Vendas Marketing Entrega Pagamentos Domínio Principal (Core Domain) • Sucesso para o negócio • Focar todos os esforços
- 31. Decompondo o problema Subdomínio Estoque RH, Financeiro Tesouraria ... Vendas Marketing Entrega Pagamentos Domínio Principal (Core Domain) • Sucesso para o negócio • Focar todos os esforços Subdomínio de Suporte • Essenciais mas não o core • Desenvolver ou comprar
- 32. Decompondo o problema Subdomínio Estoque RH, Financeiro Tesouraria ... Vendas Marketing Entrega Pagamentos Domínio Principal (Core Domain) • Sucesso para o negócio • Focar todos os esforços Subdomínio de Suporte • Essenciais mas não o core • Desenvolver ou comprar Subdomínio Genérico • Não agrega valor para o negócio • Se possível, Comprar / Github
- 33. Foco no Domínio Principal
- 34. Foco no Domínio Principal Não perca tempo e esforço para refatorar todo o seu código, foque no domínio principal! Para subdomínios de suporte e genéricos, o código bom é o suficiente. A perfeição é uma ilusão, e deve ser reservada apenas para o que é essencial O negócio não se preocupa com a qualidade do código para as áreas que não são essenciais Scott Millett
- 35. Decompondo o problema Modelo de Domínio (Domain Model) Estoque RH, Financeiro Tesouraria ... Vendas Marketing Entrega Pagamentos Representa a lógica de domínio e as regras de negócios que são relevantes para o subdomínio Modelo de Domínio Modelo de Domínio Modelo de Domínio Modelo de Domínio Modelo de Domínio Modelo de Domínio Livro
- 36. Subdomínio Estoque Subdomínio Marketing Subdomínio Vendas Subdomínio Entrega Lógica Aplicação Lógica Domínio Acesso à dados Livro Banco de Dados
- 38. Contextos Delimitados (Bounded Context) • Definem a maneira como um subdomínio será resolvido tecnicamente pela solução • Enquanto o conceito do Subdomínio pertence ao que chamamos de Espaço Problema, os Contextos Delimitados pertencem ao Espaço Solução
- 40. Contextos Delimitados (Bounded Context) Contexto de Catálogo Contexto de Precificação Contexto de Pedidos Subdomínio de Vendas Contexto de Promoções Contexto de Publicidade Subdomínio de Marketing Contexto de Estoque Subdomínio de Estoque Contexto de Pagamento Subdomínio de Pagamento Contexto de Entrega Subdomínio de Entrega Contexto de ERP Legado Subdomínio de ERP Legado
- 41. Contextos Delimitados (Bounded Context) Contexto de Catálogo Contexto de Precificação Contexto de Pedidos Subdomínio de Vendas Contexto de Promoções Contexto de Publicidade Subdomínio de Marketing Contexto de Estoque Subdomínio de Estoque Contexto de Pagamento Subdomínio de Pagamento Contexto de Entrega Subdomínio de Entrega Contexto de ERP Legado Subdomínio de ERP Legado Sistema VendoLivros Online
- 42. Estoque RH, Financeiro Tesouraria ... Vendas Marketing Entrega Pagamentos Modelo de Domínio Modelo de Domínio Modelo de Domínio Modelo de Domínio Modelo de Domínio Modelo de Domínio Livro
- 43. Contextos Delimitados (Bounded Context) Contexto de Catálogo Contexto de Precificação Contexto de Pedidos Subdomínio de Vendas Contexto de Promoções Contexto de Publicidade Subdomínio de Marketing Contexto de Estoque Subdomínio de Estoque Contexto de Pagamento Subdomínio de Pagamento Contexto de Entrega Subdomínio de Entrega Contexto de ERP Legado Subdomínio de ERP Legado • Tornar o Implícito Explicito • Define explicitamente o contexto dentro do qual um modelo se aplica. • É delimitado pela linguagem compartilhada • Protege seu modelo Livro Livro Livro Livro Livro Livro Livro
- 44. Alinhe seus times à Contextos Delimitados
- 45. Mapa de Contexto (Context Mapping)
- 46. Mapa de Contexto • Estabelece uma visão da comunicação entre as equipes • Torna as delimitações dos contextos explícitos • Fornece a visão para possíveis alterações e evoluções • Estabelece um conjunto de padrões de comunicações • Núcleo compartilhado • Cliente Fornecedor • Conformista • Parceria • Camada de Anticorrupção • Linguagem Publicada
- 47. Todas as relações tem suas motivações e seu preço...
- 48. Núcleo Compartilhado (Shared Kernel) • Dois times compartilham um subconjunto de modelo de um mesmo subdomínio • Alterações dentro do núcleo compartilhado devem ser acordadas entre as duas equipes • Integração Contínua • Geralmente é o Domínio Principal Contexto de Folha de Pagamento Contexto de Recursos Humanos Modelo de Domínio Do Funcionário Subdomínio Recurso Humanos
- 49. Baseado em direções • O Downstream é o lado do relacionamento que depende de dados ou comportamentos do lado Upstream Contexto Downstream Contexto Upstream
- 50. Cliente/Fornecedor (Customer/Supplier) • É uma relação de cliente e fornecedor • Orçar/Estimar • Planejamento da entrega • Direito a veto, negociar com o Fornecedor • Interação – O team Cliente deve estar disponível para sanar dúvidas Contexto Vendas Contexto Pedidos Customer-Supplier Downstream Upstream Consome/utiliza de
- 51. Cliente/Fornecedor (Customer/Supplier) • Testes automatizados • Escritos pela equipe de cliente (definindo a interface esperada) • Executados pela equipe Fornecedor (Para garantir que não estão quebrando nada) Contexto Vendas Contexto Pedidos Customer-Supplier Downstream Upstream Consome/utiliza de
- 52. Cliente/Fornecedor (Customer/Supplier) • Equipes de Clientes/Fornecedores tem maior chance de sucesso se elas trabalham sob a mesma gerência e compartilham os mesmos objetivos Contexto Vendas Contexto Pedidos Customer-Supplier Downstream Upstream Consome/utiliza de
- 53. Conformista (Conformist) • Não há colaboração entre o contexto downstream e o upstream • Muito comum em relacionamento com contextos que representam um sistema de terceiro, API... A A Contexto Vendas Contexto Pagamentos Conformista Downstream Upstream Consome/utiliza de
- 54. Conformista (Conformist) • Se o Upstream é uma bagunça, essa bagunça será propagada para o Downstream • É caro criar uma camada de tradução para que os objetos do upstream não corrompem o modelo do downstream A A Contexto Vendas Contexto Pagamentos Conformista Downstream Upstream Consome/utiliza de
- 55. Camada de Anticorrupção (Anti-Corruption Layer) • Criar uma camada para tradução entre os termos do Upstream para o modelo do Downstream, e vice-e-versa. • Protege o modelo de domínio de influências externas Contexto Vendas Contexto Pagamentos ACL Anti-Corruption Layer Downstream Upstream
- 56. Camada de Anticorrupção (Anti-Corruption Layer)
- 57. Parceria (Partnership) • Dependência mútua entre os contextos/equipes, elas obtém o sucesso ou fracasso juntas; • Possuem um objetivo em comum • Cooperam na evolução das interfaces para acomodar as necessidades de ambos • Entregas/Releases são alinhadas Contexto Vendas Contexto Pedidos Partnership
- 58. Caminhos separados (Separate Ways) • Quando realmente não há relacionamento entre os contextos • Quando o custo de tradução é tão grande que é preferível a duplicação de parte do modelo e que eles sigam em Caminhos separados. Contexto Publicidade Contexto Entrega
- 59. Linguagem Publicada (Published Language) • Quando você quer abrir seu contexto para integração com vários clientes • Se muitos contextos compartilham a mesma lógica de tradução, pode ser preferível que se tenha uma forma de acesso com interfaces claramente definidos • Define o protocolo de comunicação Serviço Aberto de Funcionalidades (Open/Host Service) • Quando você quer definir uma linguagem comum para comunicação
- 60. Comunicação através de API REST, JSON/XML Contexto Pedido Contexto Estoque Contexto Entrega Contexto Catálogo OHS
- 61. A estratégia sem tática é o caminho mais lento para a vitória. Sun Tzu Arte da Guerra
- 62. Projeto Tático
- 63. Arquitetura
- 67. Entidade (Entity) Tem uma identidade A igualdade é dada pelo seu ID (identidade) ad hoc setters
- 68. Objeto de Valor (Value Object) Imutável Não tem uma identidade A sua igualdade é dada pelas suas propriedades Tem Regra de negócio
- 69. Objeto de Valor (Value Object) • Reduz o code smell “Obsessão com tipos Primitivos”
- 70. Agregado Raiz Entidade Objeto Valor Agregados (Aggregate) • Compostos de Entidades ou Objetos de Valores que são encapsulados numa única classe; • Serve para manter a integridade do modelo; • Possui uma raiz de agregação (Aggregate Root); • Único repositório por raiz de agregação;
- 71. Serviço de Domínio (Domain Service) • Classes que contém uma lógica de negócio mas que não pertencem a nenhuma entidade ou objeto de valor; • Serviços não guardam estado (Stateless); • Toda chamada a um mesmo serviço, com a mesma pré-condição deve retornar o mesmo resultado. • Orquestrar entidades e encapsular regras de negócios; • Conceito de domínio que vem da LU e que envolve várias entidades; • Protege o modelo (entidade / objeto de valor)
- 72. Evento de Domínio (Domain Event) • Notifica aos interessados que algo importante aconteceu no domínio; • Exemplo de eventos: • Livro entregue • Livro foi separado • Livro foi enviado • Pedido gerado • OCP – Aberto para extensão e fechado para alteração
- 73. Critérios Técnicos Por Conceitos da LU Módulo (Module) • Divide o código por conceito (LU) e não por critério técnico; • São usados para decompor o modelo de domínio; • Permitem ao desenvolvedor ler e entender rapidamente o modelo do domínio; • Namespace / Projects
- 74. Fábrica (Factory) • Utilize construtores apenas para criação de objetos simples, • Para objetos complexos utilize fábricas • Encapsula toda a lógica necessária para criar um Agregado em um estado consistente • Centraliza a lógica de criação • Utilize os padrões GoF: • Factory Method • Abstract Factory • Builder
- 75. Repositório (Repository) • É o mecanismo que você deve usar para recuperar e persistir agregados • Persistência Agnóstica, é uma preocupação de infraestrutura, não do modelo • Pode ser útil se apoiar em estruturas de ORM (Entity Framework, NHibernate) • Um por Raiz de Agregação • Não é indicado para Relatórios e telas de consultas complexas
- 76. Especificação (Specification) • Torna a regra de negócio implícita explicita • Utilizado principalmente para validações • Permite a criação de especificações compostas (utilizando E, OU, Não)
- 77. Quando NÃO utilizar DDD Quando... • o domínio não é complexo, pode ser resolvido com um simples CRUD • a solução é muito mais técnica do que de negócio, Ex: Um framework • o Domain Expert não é acessível • você não tem um time motivado e qualificado • o processo de desenvolvimento é cascata
- 78. Adotar DDD só porque é legal Ignorar o DDD porque o domínio parece ser pouco complexo
- 79. E se você não seguir o DDD em aplicações complexas...? • Provavelmente você terá um modelo anêmico com muitos serviços • Regras de negócios ficam espalhadas em classes que não são do domínio • Difícil de mudar o sistema em uma alteração/evolução da regra de negócio • Comunicação negligenciada
- 87. Conteúdo do Curso • Introdução • Linguagem Obíquoa • Domínios Ricos vs Domínios Anêmicos • Sub Domínios • Separação em Contextos Delimitados • Organizando a Solução • Definindo as Entidades • Corrupção no Código • SOLID e Clean Code • Primitive Obsession • Value Objects • Compartilhando Informações entre Contextos Delimitados • Testando as Entidades e VOs • Commands • Fail Fast Validations • Testando os Commands • Repository Pattern • Handlers • Testando os Handlers • Queries • Testando suas Queries http://live.balta.io/