Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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.

Marcel dos Santos

September 12, 2020
Tweet

More Decks by Marcel dos Santos

Other Decks in Programming

Transcript

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

    View Slide

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

    View Slide

  3. @phpsp
    phpsp.org.br

    View Slide

  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

    View Slide

  5. O que é 

    domain-driven design?

    View Slide

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

    View Slide

  7. o termo é o nome de um livro famoso
    conhecido como "livro azul" escrito
    por Eric Evans em 2003

    View Slide

  8. View Slide

  9. "Domain-Driven Design: Tackling
    Complexity in the Heart of Software"

    View Slide

  10. e, como diz o título do livro, domain-driven
    design é sobre atacar as complexidades
    no coração do software

    View Slide

  11. o domínio é o coração do software e onde
    estão as regras de negócio

    View Slide

  12. "The heart of software is its ability to solve
    domain-related problems for its user." 

    ― Eric Evans, Domain-Driven Design

    View Slide

  13. o domínio possui uma complexidade
    intrínseca, isto é, a complexidade do
    problema a ser resolvido

    View Slide

  14. e, segundo Evans, devemos nos interessar
    mais pela complexidade do domínio

    View Slide

  15. Complexidade acidental
    e complexidade essencial

    View Slide

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

    View Slide

  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

    View Slide

  18. a complexidade essencial é aquela que é
    inerente ao problema a ser resolvido

    View Slide

  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

    View Slide

  20. a complexidade essencial é aquela que
    não pode ser evitada e está relacionada
    a complexidade do domínio

    View Slide

  21. para entender melhor o domínio devemos
    conversar com os especialistas de domínio

    View Slide

  22. Linguagem Ubíqua ou
    Linguagem Onipresente

    View Slide

  23. a linguagem ubíqua ou linguagem
    onipresente é uma linguagem comum
    utilizada para expressar o domínio

    View Slide

  24. a linguagem ubíqua é a linguagem criada
    pelo time de desenvolvimento em conjunto
    com os especialistas de domínio

    View Slide

  25. ela deve expressar o negócio na
    comunicação falada, em documentos
    e na forma de código

    View Slide

  26. ela surge da conversa com especialistas
    de domínio e deve ser compreendida
    por todos e sem ambiguidade

    View Slide

  27. o código desenvolvido deverá utilizar a
    linguagem ubíqua no nome de módulos,
    classes, métodos e funções

    View Slide

  28. a linguagem ubíqua existe dentro de um
    contexto específico, isto é, um contexto
    delimitado

    View Slide

  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"

    View Slide

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

    View Slide

  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

    View Slide

  32. Big Ball of Mud

    View Slide

  33. uma "big ball of mud" ou grande bola de
    lama é um código com uma arquitetura mal
    definida…

    View Slide

  34. …e que correções e pequenas evoluções se
    tornam um grande desafio pela dificuldade
    de compreender o código

    View Slide

  35. View Slide

  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

    View Slide

  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

    View Slide

  38. Subdomínios

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  42. subdomínio de suporte


    - suporta o domínio principal


    - é importante mas não representa o
    negócio principal

    View Slide

  43. subdomínio genérico


    - não possui relação direta com o domínio
    principal


    - geralmente faz uso de software terceiro

    View Slide

  44. View Slide

  45. Contextos Delimitados 

    ou Bounded Contexts

    View Slide

  46. contexto delimitado ou bounded context é
    uma fronteira conceitual onde reside o
    modelo de domínio e a linguagem ubíqua

    View Slide

  47. os contextos delimitados buscam delimitar
    o seu domínio complexo em contextos
    baseados nas intenções do negócio

    View Slide

  48. a linguagem ubíqua dentro de um contexto
    permite definir o limite de conceitos que
    podem ser diferentes dentro de diferentes
    contextos

    View Slide

  49. exemplo 04


    uma entidade Usuario no contexto A pode
    ser diferente de uma mesma entidade
    Usuario no contexto B

    View Slide

  50. cada contexto delimitado possui a sua
    própria linguagem ubíqua

    View Slide

  51. isto significa que você deve delimitar as
    intenções de suas entidades com base no
    contexto que ela pertence

    View Slide

  52. cada contexto delimitado pode ter a sua
    própria arquitetura, modelo de persistência
    e ser desenvolvido por um time diferente

    View Slide

  53. um contexto delimitado é um reflexo da
    estrutura organizacional que se possui na
    empresa

    View Slide

  54. os contextos delimitados podem se
    comunicar de diversas maneiras como, por
    exemplo, utilizando APIs REST ou sistema
    de mensageria

    View Slide

  55. um subdomínio é relacionado ao problema
    de domínio e o bounded context é
    relacionado à solução do problema

    View Slide

  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

    View Slide

  57. Mapas de Contextos 

    ou Context Maps

    View Slide

  58. o mapa de contextos permite documentar
    os contextos delimitados e desenhar o
    relacionamento entre eles

    View Slide

  59. o mapa de contextos é uma ferramenta
    estratégica que mostra a relação entre os
    subdomínios

    View Slide

  60. View Slide

  61. os padrões de compartilhamento são:


    - núcleo compartilhado

    - produtor-consumidor

    - conformista

    - parceria

    - camada anticorrupção

    View Slide

  62. Design Tático e 

    Design Estratégico

    View Slide

  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

    View Slide

  64. o design tático refere-se a implementação
    de código

    View Slide

  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

    View Slide

  66. os padrões não são exclusividade do
    domain-driven design, isto é, eles já eram
    conhecidos e utilizados anteriormente

    View Slide

  67. o design estratégico refere-se ao
    relacionamento e comunicação entre os
    subdomínios

    View Slide

  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

    View Slide

  69. Arquitetura em
    Camadas

    View Slide

  70. a arquitetura em camadas é utilizada para
    organizar a aplicação e permite separá-la em
    camadas com responsabilidades específicas

    View Slide

  71. View Slide

  72. interface de usuário


    responsável por exibir informações e
    interpretar comandos do usuário

    View Slide

  73. aplicação


    responsável por conectar a camada de
    interface de usuário com as outras
    camadas

    View Slide

  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

    View Slide

  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

    View Slide

  76. "Isolating the domain implementation is a
    prerequisite for domain-driven design."

    ― Eric Evans

    View Slide

  77. Blocos de Construção

    ou Building Blocks

    View Slide

  78. entidades


    são objetos que possuem uma identidade

    View Slide

  79. objetos de valor


    são objetos que carregam valor, não
    possuem identidade e são imutáveis

    View Slide

  80. View Slide

  81. agregados


    um agregado é, de forma simples, um
    conjunto entidades e objetos de valor

    View Slide

  82. agregados


    é um elemento conceitual que é responsável
    por conter outras entidades que não podem
    ser acessadas de fora

    View Slide

  83. agregados


    para isso utiliza-se o encapsulamento e a lei
    de Demeter e sempre falaremos com o
    aggregate root

    View Slide

  84. View Slide

  85. eventos de domínio


    representa algo que ocorreu no domínio e
    que é desejado que outras partes tenham
    conhecimento

    View Slide

  86. eventos de domínio


    permite expressar de forma explícita um
    efeito colateral

    View Slide

  87. View Slide

  88. fábricas


    classes responsáveis pela criação de
    agregados ou objetos de valor

    View Slide

  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

    View Slide

  90. serviços


    classes que contém regra de negócio mas
    que não pertencem a nenhuma entidade ou
    objeto de valor

    View Slide

  91. repositórios


    um repositório é responsável por acessar
    uma camada de dados externa

    View Slide

  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)

    View Slide

  93. módulos


    abstrações que têm por objetivo agrupar
    classes por um determinado conceito do
    domínio

    View Slide

  94. módulos


    pode-se utilizar pacotes em Java,
    namespaces em PHP ou módulos em
    JavaScript

    View Slide

  95. módulos


    o agrupamento não deve ser feito segundo
    conceitos de infraestrutura e, sim, conceitos
    de domínio

    View Slide

  96. View Slide

  97. Conclusão

    View Slide

  98. o foco do domain-driven design é atender
    as necessidades do domínio, ou seja, a
    complexidade essencial

    View Slide

  99. para isso, deve-se utilizar a linguagem
    onipresente para aproximar os especialistas
    de domínio da equipe técnica

    View Slide

  100. "DDD é primariamente sobre modelar uma
    linguagem ubíqua em contexto delimitado" 

    ― Vaughn Vernon

    View Slide

  101. domain-driven design não é sobre
    arquitetura e, sim, sobre priorizar o domínio

    View Slide

  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

    View Slide

  103. vá em frente e divirta-se!

    View Slide

  104. Referências

    View Slide

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

    View Slide

  106. Avalie!

    View Slide

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

    View Slide