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 full-size slide

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

    View full-size slide

  3. @phpsp
    phpsp.org.br

    View full-size 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 full-size slide

  5. O que é 

    domain-driven design?

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    ― Eric Evans, Domain-Driven Design

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  14. Complexidade acidental
    e complexidade essencial

    View full-size slide

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

    View full-size slide

  16. 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 full-size slide

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

    View full-size slide

  18. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

  21. Linguagem Ubíqua ou
    Linguagem Onipresente

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  28. 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 full-size slide

  29. 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 full-size slide

  30. "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 full-size slide

  31. Big Ball of Mud

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  34. "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 full-size slide

  35. "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 full-size slide

  36. Subdomínios

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  39. 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 full-size slide

  40. subdomínio de suporte


    - suporta o domínio principal


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

    View full-size slide

  41. subdomínio genérico


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


    - geralmente faz uso de software terceiro

    View full-size slide

  42. Contextos Delimitados 

    ou Bounded Contexts

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  46. exemplo 04


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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  53. "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 full-size slide

  54. Mapas de Contextos 

    ou Context Maps

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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


    - núcleo compartilhado

    - produtor-consumidor

    - conformista

    - parceria

    - camada anticorrupção

    View full-size slide

  58. Design Tático e 

    Design Estratégico

    View full-size slide

  59. 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 full-size slide

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

    View full-size slide

  61. é 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 full-size slide

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

    View full-size slide

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

    View full-size slide

  64. "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 full-size slide

  65. Arquitetura em
    Camadas

    View full-size slide

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

    View full-size slide

  67. interface de usuário


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

    View full-size slide

  68. aplicação


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

    View full-size slide

  69. 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 full-size slide

  70. 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 full-size slide

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

    ― Eric Evans

    View full-size slide

  72. Blocos de Construção

    ou Building Blocks

    View full-size slide

  73. entidades


    são objetos que possuem uma identidade

    View full-size slide

  74. objetos de valor


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

    View full-size slide

  75. agregados


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

    View full-size slide

  76. agregados


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

    View full-size slide

  77. agregados


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

    View full-size slide

  78. eventos de domínio


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

    View full-size slide

  79. eventos de domínio


    permite expressar de forma explícita um
    efeito colateral

    View full-size slide

  80. fábricas


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

    View full-size slide

  81. 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 full-size slide

  82. serviços


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

    View full-size slide

  83. repositórios


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

    View full-size slide

  84. 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 full-size slide

  85. módulos


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

    View full-size slide

  86. módulos


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

    View full-size slide

  87. módulos


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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    ― Vaughn Vernon

    View full-size slide

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

    View full-size slide

  92. 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 full-size slide

  93. vá em frente e divirta-se!

    View full-size slide

  94. Referências

    View full-size slide

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

    View full-size slide

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

    View full-size slide