Introdução a Domain-Driven Design

Apresentação realizada no Meetup
https://www.meetup.com/pt-BR/qualyteam/events/243888032/

1. Domain- Driven Design Leandro A. Vieira Maicon C. Pereira

2. Domain- Driven Design

3. 2003 Evans 2013 Vernon 2015 Millet

4. Complexidade no Software Essencial Complexidade da Lógica do Negócio/Domínio Acidental Complexidade da Solução Técnica + Código Legado

5. 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”

6. “DDD é sobre a redução de complexidade no software” Eric Evans

7. DDD é sobre o negócio

8. 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

9. 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., Isso é o Domínio. 

10. DDD é sobre criar modelos altamente expressivos

11. O que é um Modelo? Simplificação da realidade Mostra alguns aspectos da realidade ou uma ideia de interesse

12. Como você representa seu modelo?

13. Como você representa seu modelo? User Stories ( Text ) ?

14. Como você representa seu modelo?

15. Como você representa seu modelo?

16. Modelo é uma representação mental Todo o resto são apenas ferramentas de comunicação

17. Como construir um modelo no DDD ?

18. 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

19. Linguagem Ubíqua Baseado em uma linguagem comum Expresso em todos os níveis

20. #SQN

21. Tática sem estratégia é o ruído antes da derrota. Sun Tzu Arte da Guerra

22. 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

23. Projeto Estratégico do DDD

24. 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.

25. Decompondo o problema

26. Lei de Conway 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)

27. 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

28. 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

29. 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

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 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

31. Foco no Domínio Principal

32. 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

33. 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

34. 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

35. Estoque Vendas Marketing Entrega

36. 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

37. Estoque RH, Financeiro Tesouraria ... Vendas Marketing Entrega Pagamentos

38. 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

39. 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

40. 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

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 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

42. Alinhe seus times à Contextos Delimitados

43. Mapa de Contexto ( Context Mapping )

44. 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

45. Todas as relações tem suas motivações e seu preço...

46. 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

47. Baseado em direções O Downstream é o lado do relacionamento que depende de dados ou comportamentos do lado Upstream Contexto Downstream Contexto Upstream Consome/utiliza de

48. 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

49. 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

50. 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

51. 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

52. 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

53. 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

54. Camada de Anticorrupção ( Anti-Corruption Layer )

55. 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

56. 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

57. 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

58. Comunicação através de API REST, JSON/XML Contexto Pedido Contexto Estoque Contexto Entrega Contexto Catálogo OHS

59. A estratégia sem tática é o caminho mais lento para a vitória. Sun Tzu Arte da Guerra

60. Projeto Tático

61. Arquitetura

62. Model-Driven Design

63. Entidade ( Entity ) Tem uma identidade A igualdade é dada pelo seu ID (identidade) ad hoc setters

64. Objeto de Valor ( Value Object ) Imutável Não tem uma identidade A sua igualdade é dada pelas suas propriedades Tem Regra de negócio

65. Objeto de Valor ( Value Object ) Reduz o code smell “Obsessão com tipos Primitivos”

66. 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;

67. 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)

68. 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

69. 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

70. 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

71. 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

72. 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)

73. 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

74. Adotar DDD só porque é legal Ignorar o DDD porque o domínio parece ser pouco complexo

75. 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

76. Pra saber mais...

77. 2003 Evans 2006 Avram & Marinescu 2013 Vernon 2016 Vernon 2014 Evans 2009 Haywood 2006 Nilsson 2015 Millet 2008 McCarthy 2017 Buenosvinos 2011 La Torre

78. https://elearn.domainlanguage.com/

79. http://www.informit.com/store/domain-driven-design-livelessons-video-training-9780134597324?ranMID=24808

80. https://www.sympla.com.br/acampamento-de-base-ddd-enriquecendo-a-evolucao-de-suas-aplicacoes__144198

81. https://www.sympla.com.br/microservice-architecture-design-e-implementacao-net__181411

82. http://www.eduardopires.net.br/curso-de-arquitetura-de-software-dotnet/

83. 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/

84. Dúvidas? Obrigado!