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