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.

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