[TDC SP 2025] Então você quer ser um praticante de DDD

Entenda do que se trata o DDD, as partes fundamentais, design estratégico e tático, e quais os próximos passos para se tornar um praticante de DDD.

Transcript

1. Então você quer ser um praticante de DDD @talyssonoc
2. Talysson Oliveira Software architect & Chief Learning Officer na Codeminer42 @talyssonoc beacons.ai/talyssonoc
3. 2024 2025 2015
4. codeminer42.com @codeminer42
5. Existem muitos equívocos em torno de Domain-Driven Design
6. - DDD só adiciona complexidade desnecessária no código - DDD é um tipo de arquitetura de software - DDD é uma forma de organizar pastas e arquivos - Aplicações que aplicam DDD tem arquivos demais - Para usar DDD tem que usar um monte de design patterns - DDD torna o código difícil de entender - Nunca precisei usar DDD pro meu software funcionar - …
7. Resumos, vídeos e "exemplos" que pulam as partes importantes 😱
8. Esqueça tudo que você já ouviu falar sobre DDD
9. Pare de achar que DDD é uma arquitetura de software
10. Inclusive pare de associar DDD a código por um instante
11. Para praticar DDD, você precisa saber do que ele se trata
12. "O coração de um software é sua habilidade de resolver problemas relacionados ao domínio para seus usuários" Domain-Driven Design - Eric Evans
13. Domínio - Finanças - Saúde - Educação - Comércio - Aviação - Mineração - Transporte - … Problema Sistema de abstrações que descrevem aspectos específicos do domínio, usado para resolver problemas relacionados ao domínio Modelo
14. Automóveis (Domínio) Automodelo
15. Como é cultivado o modelo?
16. Especialistas de domínio Especialistas de desenvolvimento
17. Especialistas de domínio Especialistas de desenvolvimento Modelo
18. Especialistas de domínio Especialistas de desenvolvimento Modelo Linguagem ubíqua
19. DDD é uma abordagem de desenvolvimento onde: - Focamos no domínio - Exploramos modelos colaborativamente entre especialistas de domínio e de desenvolvimento - Falamos uma linguagem ubíqua
20. O modelo e a linguagem ubíqua são universais? Não (pelo menos na maior parte dos casos)
21. Carro
22. Produto
23. Um modelo e sua linguagem ubíqua são limitados à um contexto
24. Projetos tendem a ter múltiplos modelos em atividade ao mesmo tempo
25. Projetos tendem a ter múltiplos contextos em atividade ao mesmo tempo
26. Contexto limitado (bounded context) Uma divisão onde um modelo e uma linguagem ubíqua se aplicam
29. Mapeamento de contextos - Definição dos pontos de contato entre modelos, delimitando mecanismos de compartilhamento, isolamento e influência entre eles - Descoberta das relações entre os contextos que impõe restrições na natureza do modelo ou no ritmo viável para mudanças - Contextos que se dependem mutuamente - Contextos que suportam múltiplos outros contextos - Contextos que dependem unilateralmente de outros - Contextos que nunca precisam interagir entre si - Muitas vezes a natureza dessa relação pode ser inclusive não-técnica - Ex.: serviço terceirizado de processamento de pagamentos
31. Design estratégico
32. Fonte: <https://twitter.com/ScottWlaschin/status/1225761214699098113>
33. Por favor, não achem que DDD é o só o que falaremos daqui pra frente ⚠
34. Vamos falar de código
35. Modelo Sistema de abstrações que descrevem aspectos específicos do domínio, usado para resolver problemas relacionados ao domínio
36. Model-Driven Design
37. id status shippingAddress estimatedDelivery Pedido
38. id: 42 status: pending shippingAddress: Rua ABC estimatedDelivery: 10/10/2025 Pedido #42 t
39. id: 42 status: pending shippingAddress: Rua ABC estimatedDelivery: 10/10/2025 id: 42 status: pending shippingAddress: Av. XYZ estimatedDelivery: 10/10/2025 Pedido #42 t
40. id: 42 status: pending shippingAddress: Rua ABC estimatedDelivery: 10/10/2025 id: 42 status: shipped shippingAddress: Av. XYZ estimatedDelivery: 11/11/2025 Pedido #42 t id: 42 status: pending shippingAddress: Av. XYZ estimatedDelivery: 10/10/2025
41. id: 42 status: pending shippingAddress: Rua ABC estimatedDelivery: 10/10/2025 id: 42 status: shipped shippingAddress: Av. XYZ estimatedDelivery: 11/11/2025 Pedido #42 t id: 42 status: pending shippingAddress: Av. XYZ estimatedDelivery: 10/10/2025 Identidade + ciclo de continuidade = Entidade (entity)
43. red green blue Cor
44. red: 255 green: 0 blue: 0 Vermelho
45. red: 255 green: 0 blue: 0 Vermelho red: 255 green: 0 blue: 255 Rosa
46. red: 255 green: 0 blue: 0 Vermelho red: 255 green: 0 blue: 255 Rosa red: 110 green: 200 blue: 80 Verde
47. red: 255 green: 0 blue: 0 Vermelho red: 255 green: 0 blue: 255 Rosa red: 110 green: 200 blue: 80 Verde Ausência de identidade + significado proveniente dos valores dos atributos = Objeto de valor (value object)
49. id status shippingAddress estimatedDelivery Pedido color carId tires Personalizações airConditioner mediaPlayer Extras paymentMethod totalPrice Pagamento
50. id status shippingAddress estimatedDelivery Pedido color carId tires Personalizações airConditioner mediaPlayer Extras paymentMethod totalPrice Pagamento
51. id status shippingAddress estimatedDelivery Pedido color carId tires Personalizações airConditioner mediaPlayer Extras paymentMethod totalPrice Pagamento
52. id status shippingAddress estimatedDelivery Pedido color carId tires Personalizações airConditioner mediaPlayer Extras paymentMethod totalPrice Pagamento Entidade principal + fronteira de consistência conceitual = Agregado (aggregate) Raiz do agregado (aggregate root)
54. buscar pedido por id buscar pedidos por status persistir um pedido Pedido (agregado)
55. buscar pedido por id buscar pedidos por status Ações de interesse do domínio persistir um pedido Pedido (agregado)
56. buscar pedido por id buscar pedidos por status Ações de interesse do domínio Agregados que requerem acesso direto + conjunto de ações de persistência de interesse do domínio = Repositório (repository) persistir um pedido Pedido (agregado)
57. = Repositório (repository) OrderRepository + findById(id) + findAllByStatus(status) + store(pedido) Agregados que requerem acesso direto + conjunto de ações de persistência de interesse do domínio
59. Design estratégico
60. Design estratégico Design tático
61. Combine design estratégico com design tático! Fuja do suposto "DDD lite"
62. Quais os próximos passos?
63. Próximos passos 1. Certifique-se que entendeu que DDD não é primariamente sobre código 2. Não busque atalhos, fuja do suposto "DDD lite" 3. Leia o minibook DDD Quickly <infoq.com/minibooks/domain-driven-design-quickly> 4. Assista a talk "7 Reasons Why DDD Projects Fail", Greg Young <vimeo.com/13824218> 5. Aprenda a base de maneira sólida, não faça isso com pressa - Domain-Driven Design, Eric Evans (the blue book) ou Learning Domain-Driven Design, Vlad Khononov 6. Pratique! 7. Aprofunde os conhecimentos - Implementing Domain-Driven Design, Vaughn Vernon (the red book) 8. Pratique, não busque atalhos, e fuja do suposto "DDD lite"!
64. Obrigado! @talyssonoc beacons.ai/talyssonoc @codeminer42 codeminer42.com