Começando com Domain-Driven Design

Começando com Domain-Driven Design

Nesta palestra iremos introduzir o que é domain-driven design e como a utilização de seus fundamentos podem ajudar na construção de uma aplicação mais robusta e flexível. Serão apresentados conceitos como linguagem ubíqua, model-driven design, bounded contexts e os principais blocos de construção (entidades, objetos de valor, agregados entre outros). Assista essa palestra e conheça o valor que o domain-driven design entrega ao permitir aplicações mais expressivas e projetadas para mudança.

52711e2157a6fed933b0361cc06a6953?s=128

Marcel dos Santos

September 12, 2020
Tweet

Transcript

  1. Marcel Gonçalves dos Santos @marcelgsantos domain-driven design introdução a

  2. pensandonaweb.com.br desenvolvedor web full-stack Marcel Gonçalves dos Santos @marcelgsantos

  3. @phpsp phpsp.org.br

  4. Interaja nas mídias sociais!
 
 - fale sobre o evento,

    palestrantes e conteúdo - tire fotos do evento e publique
 - interaja com outros participantes do evento - tire dúvidas ou dê feedbacks para os palestrantes
  5. O que é 
 domain-driven design?

  6. o domain-driven design é uma abordagem para o desenvolvimento de

    softwares complexos
  7. o termo é o nome de um livro famoso conhecido

    como "livro azul" escrito por Eric Evans em 2003
  8. None
  9. "Domain-Driven Design: Tackling Complexity in the Heart of Software"

  10. e, como diz o título do livro, domain-driven design é

    sobre atacar as complexidades no coração do software
  11. o domínio é o coração do software e onde estão

    as regras de negócio
  12. "The heart of software is its ability to solve domain-related

    problems for its user." 
 ― Eric Evans, Domain-Driven Design
  13. o domínio possui uma complexidade intrínseca, isto é, a complexidade

    do problema a ser resolvido
  14. e, segundo Evans, devemos nos interessar mais pela complexidade do

    domínio
  15. Complexidade acidental e complexidade essencial

  16. a complexidade acidental é aquela que é decorrente da solução

    adotada
  17. exemplo 01 
 escolher entre utilizar monolitos ou microsserviços, framework

    A ou B, banco de dados relacionais ou não-relacionais são exemplos de complexidades acidentais
  18. a complexidade essencial é aquela que é inerente ao problema

    a ser resolvido
  19. exemplo 02 
 a coordenação de motoristas de aplicativos, isto

    é, identificar os motoristas disponíveis nas imediações da solicitação de uma chamada é um exemplo de complexidade essencial pois faz parte do problema
  20. a complexidade essencial é aquela que não pode ser evitada

    e está relacionada a complexidade do domínio
  21. para entender melhor o domínio devemos conversar com os especialistas

    de domínio
  22. Linguagem Ubíqua ou Linguagem Onipresente

  23. a linguagem ubíqua ou linguagem onipresente é uma linguagem comum

    utilizada para expressar o domínio
  24. a linguagem ubíqua é a linguagem criada pelo time de

    desenvolvimento em conjunto com os especialistas de domínio
  25. ela deve expressar o negócio na comunicação falada, em documentos

    e na forma de código
  26. ela surge da conversa com especialistas de domínio e deve

    ser compreendida por todos e sem ambiguidade
  27. o código desenvolvido deverá utilizar a linguagem ubíqua no nome

    de módulos, classes, métodos e funções
  28. a linguagem ubíqua existe dentro de um contexto específico, isto

    é, um contexto delimitado
  29. exemplo 03
 
 um especialista de domínio descreve o seguinte

    cenário: "o cliente poderá finalizar o pedido quando estiver satisfeito com os itens em seu carrinho de compras"
  30. no código teremos:
 
 - uma classe para a entidade

    Cliente
 - uma classe para a entidade 
 CarrinhoDeCompras
 - um método para a ação finalizarPedido()
  31. "To communicate effectively, the code must be based on the

    same language used to write the requirements—the same language that the developers speak with each other and with domain experts." 
 ― Eric Evans, Domain-Driven Design
  32. Big Ball of Mud

  33. uma "big ball of mud" ou grande bola de lama

    é um código com uma arquitetura mal definida…
  34. …e que correções e pequenas evoluções se tornam um grande

    desafio pela dificuldade de compreender o código
  35. None
  36. "A big ball of mud is haphazardly structured, sprawling, sloppy,

    duct-tape and bailing wire, spaghetti code jungle.” 
 ― Brian Foote and Joseph Yoder, 1999
  37. "Uma grande bola de lama é uma selva de código

    espaguete, aleatoriamente estruturado, espalhado, desleixado e cheio de fita adesiva." 
 ― Brian Foote and Joseph Yoder, 1999
  38. Subdomínios

  39. um domínio costuma ter separações que são chamadas subdomínios

  40. os tipos de subdomínios são: subdomínio principal, subdomínio de suporte

    e subdomínio genérico
  41. subdomínio principal
 
 - domínio que traz valor para o

    negócio e onde fica a lógica principal
 
 - é a atividade principal da empresa e geralmente é um software feito sob medida
  42. subdomínio de suporte
 
 - suporta o domínio principal
 


    - é importante mas não representa o negócio principal
  43. subdomínio genérico
 
 - não possui relação direta com o

    domínio principal
 
 - geralmente faz uso de software terceiro
  44. None
  45. Contextos Delimitados 
 ou Bounded Contexts

  46. contexto delimitado ou bounded context é uma fronteira conceitual onde

    reside o modelo de domínio e a linguagem ubíqua
  47. os contextos delimitados buscam delimitar o seu domínio complexo em

    contextos baseados nas intenções do negócio
  48. a linguagem ubíqua dentro de um contexto permite definir o

    limite de conceitos que podem ser diferentes dentro de diferentes contextos
  49. exemplo 04
 
 uma entidade Usuario no contexto A pode

    ser diferente de uma mesma entidade Usuario no contexto B
  50. cada contexto delimitado possui a sua própria linguagem ubíqua

  51. isto significa que você deve delimitar as intenções de suas

    entidades com base no contexto que ela pertence
  52. cada contexto delimitado pode ter a sua própria arquitetura, modelo

    de persistência e ser desenvolvido por um time diferente
  53. um contexto delimitado é um reflexo da estrutura organizacional que

    se possui na empresa
  54. os contextos delimitados podem se comunicar de diversas maneiras como,

    por exemplo, utilizando APIs REST ou sistema de mensageria
  55. um subdomínio é relacionado ao problema de domínio e o

    bounded context é relacionado à solução do problema
  56. "Se os limites dos nossos serviços alinham- se aos contextos

    delimitados do nosso domínio, nós começamos bem para garantir que nossos microsserviços estão com baixo acoplamento e alta coesão" 
 ― Sam Newman
  57. Mapas de Contextos 
 ou Context Maps

  58. o mapa de contextos permite documentar os contextos delimitados e

    desenhar o relacionamento entre eles
  59. o mapa de contextos é uma ferramenta estratégica que mostra

    a relação entre os subdomínios
  60. None
  61. os padrões de compartilhamento são:
 
 - núcleo compartilhado
 -

    produtor-consumidor
 - conformista
 - parceria
 - camada anticorrupção
  62. Design Tático e 
 Design Estratégico

  63. o domain-driven design fornece um conjunto de conceitos e padrões

    para auxiliar no projeto do software em nível tático e estratégico
  64. o design tático refere-se a implementação de código

  65. é no design tático que falamos sobre entidades, objetos de

    valor, serviços de domínio, eventos de domínio, agregados, repositórios e fábricas
  66. os padrões não são exclusividade do domain-driven design, isto é,

    eles já eram conhecidos e utilizados anteriormente
  67. o design estratégico refere-se ao relacionamento e comunicação entre os

    subdomínios
  68. "Design estratégico é como fazer o rascunho antes de entrar

    nos detalhes da implementação. Destaca o que é estrategicamente importante para o seu negócio, como dividir o trabalho por importância e como fazer integrações da melhor maneira." 
 ― Vaughn Vernon
  69. Arquitetura em Camadas

  70. a arquitetura em camadas é utilizada para organizar a aplicação

    e permite separá-la em camadas com responsabilidades específicas
  71. None
  72. interface de usuário
 
 responsável por exibir informações e interpretar

    comandos do usuário
  73. aplicação
 
 responsável por conectar a camada de interface de

    usuário com as outras camadas
  74. domínio
 
 responsável por conter os conceitos e regras de

    negócio relacionados ao domínio e é o principal foco do domain-driven design
  75. infraestrutura
 
 responsável por fornecer os recursos técnicos que dão

    suporte às outras camadas como persistência de dados e I/O
  76. "Isolating the domain implementation is a prerequisite for domain-driven design."


    ― Eric Evans
  77. Blocos de Construção
 ou Building Blocks

  78. entidades
 
 são objetos que possuem uma identidade

  79. objetos de valor
 
 são objetos que carregam valor, não

    possuem identidade e são imutáveis
  80. None
  81. agregados
 
 um agregado é, de forma simples, um conjunto

    entidades e objetos de valor
  82. agregados
 
 é um elemento conceitual que é responsável por

    conter outras entidades que não podem ser acessadas de fora
  83. agregados
 
 para isso utiliza-se o encapsulamento e a lei

    de Demeter e sempre falaremos com o aggregate root
  84. None
  85. eventos de domínio
 
 representa algo que ocorreu no domínio

    e que é desejado que outras partes tenham conhecimento
  86. eventos de domínio
 
 permite expressar de forma explícita um

    efeito colateral
  87. None
  88. fábricas
 
 classes responsáveis pela criação de agregados ou objetos

    de valor
  89. fábricas
 
 agregados são complexos e as fábricas permitem extrair

    a complexidade de criação de uma agregado de sua definição
  90. serviços
 
 classes que contém regra de negócio mas que

    não pertencem a nenhuma entidade ou objeto de valor
  91. repositórios
 
 um repositório é responsável por acessar uma camada

    de dados externa
  92. repositórios
 
 o domínio não deve estar acoplado a um

    banco de dados e, para isso, utiliza-se abstrações (e, mais especificamente, o padrão data mapper)
  93. módulos
 
 abstrações que têm por objetivo agrupar classes por

    um determinado conceito do domínio
  94. módulos
 
 pode-se utilizar pacotes em Java, namespaces em PHP

    ou módulos em JavaScript
  95. módulos
 
 o agrupamento não deve ser feito segundo conceitos

    de infraestrutura e, sim, conceitos de domínio
  96. None
  97. Conclusão

  98. o foco do domain-driven design é atender as necessidades do

    domínio, ou seja, a complexidade essencial
  99. para isso, deve-se utilizar a linguagem onipresente para aproximar os

    especialistas de domínio da equipe técnica
  100. "DDD é primariamente sobre modelar uma linguagem ubíqua em contexto

    delimitado" 
 ― Vaughn Vernon
  101. domain-driven design não é sobre arquitetura e, sim, sobre priorizar

    o domínio
  102. uma aplicação construída com domain- driven design pode fazer uso

    de qualquer decisão arquitetural como arquitetura hexagonal, CQRS ou clean architecture
  103. vá em frente e divirta-se!

  104. Referências

  105. bit.ly/palestra-domain-driven-design

  106. Avalie!

  107. @marcelgsantos speakerdeck.com/marcelgsantos Obrigado. Perguntas?