[DDD Europe 2026] So you want to be a DDD practitioner

What if it's the first time someone you know hears about DDD? Or maybe they heard it before but never got to grasp it? Where to begin? What are the key concepts? What should they read, or watch, or do to become a DDD practitioner? How could you guide them?

Transcript

1. So you want to be a DDD practitioner
2. Talysson Oliveira Software architect & Chief Learning Officer at Codeminer42 @talyssonoc talysson.com
3. codeminer42.com ai.codeminer42.com @codeminer42
4. dddbrasil.com.br linkedin.com/company/dddbrasil youtube.com/@ddd-brasil
5. There is a lot of misunderstandings around Domain-Driven Design
6. - DDD only adds unnecessary complexity - DDD is a type of software architecture - DDD is a way to organize files and folders - DDD applications have too many files - You have to use a lot of design patterns - DDD makes the code harder to understand - "I never needed DDD for my software to work!" - …
7. "All you need to know about DDD" or "DDD lite" tutorials that skip all the important parts
8. Forget everything you know about DDD for a second
9. Also, stop relating DDD to code
10. To practice DDD, you have to know what it's all about
11. "The heart of software is its ability to solve domain related problems for the user" Domain-Driven Design - Eric Evans
12. Domain - Finance - Health - Education - Shopping - Manufacturing - Mining - Cargo - … Problem "A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain" Model
13. Model Car industry Car sales Car Customer Order Payment Customisations Financing terms Colour Extras …
14. How are domain models cultivated?
15. Domain experts Technical experts (developers, designers, …)
16. Domain experts Technical experts (developers, designers, …)
17. Domain experts Technical experts (developers, designers, …) Model
18. Domain experts Technical experts (developers, designers, …) Ubiquitous language Model
19. DDD is a development approach where: - Focus on the core domain - Explore models in creative collaboration - Speak a ubiquitous language
20. Are the model and the ubiquitous language universal? No (at least not most of the time)
21. Car
22. Product
23. A model and its ubiquitous language are bounded by a context
24. Projects can have multiple models in play at the same time
25. Projects can have multiple contexts in play at the same time
26. Bounded context A boundary within which a model and a ubiquitous language apply
28. Context mapping - Discover the relationships between the contexts - How they share/hide information and influence each other - They place constraints on the nature of the models and pace of change - Contexts that depend on each other mutually (partnership) - Contexts that need to support multiple dependent contexts (open host service) - Contexts that depend unilaterally of some context (conformist) - Contexts that don't even need to know about each other (separate ways) - … - Sometimes you have no control over that relationship! - e.g.: a 3rd party payment processor system
29. DDD is not about code
30. Source: <https://twitter.com/ScottWlaschin/status/1225761214699098113>
31. DDD is about communication and knowledge management
33. Strategic design
34. Strategic design
35. Please, do not think DDD is only what we're going to talk from now on ⚠
36. We'll talk about code
37. Model A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain
38. Model-driven design An explanation by example
39. id status shippingAddress estimatedDelivery Order
40. id: 42 status: pending shippingAddress: ABC St. estimatedDelivery: 10/10/2026 Order #42 t
41. id: 42 status: pending shippingAddress: ABC St. estimatedDelivery: 10/10/2026 id: 42 status: pending shippingAddress: XYZ Hwy. estimatedDelivery: 10/10/2026 Order #42 t
42. id: 42 status: pending shippingAddress: ABC St. estimatedDelivery: 10/10/2026 id: 42 status: shipped shippingAddress: Av. XYZ estimatedDelivery: 11/11/2026 Order #42 t id: 42 status: pending shippingAddress: XYZ Hwy. estimatedDelivery: 10/10/2026
43. id: 42 status: pending shippingAddress: ABC St. estimatedDelivery: 10/10/2026 id: 42 status: shipped shippingAddress: Av. XYZ estimatedDelivery: 11/11/2026 Order #42 t id: 42 status: pending shippingAddress: XYZ Hwy. estimatedDelivery: 10/10/2026 Identity + life cycle = Entity In your model
45. red green blue Colour
46. red: 255 green: 0 blue: 0 Red red: 255 green: 0 blue: 255 Pink red: 110 green: 200 blue: 80 Green
47. red: 255 green: 0 blue: 0 Red red: 255 green: 0 blue: 255 Pink red: 110 green: 200 blue: 80 Green No conceptual identity + significance comes from describing things = Value object In your model
49. id status shippingAddress estimatedDelivery Order colour carId tires Customisations airConditioner mediaPlayer Extras paymentMethod totalPrice Payment
50. id status shippingAddress estimatedDelivery Order colour carId tires Customisations airConditioner mediaPlayer Extras paymentMethod totalPrice Payment
51. id status shippingAddress estimatedDelivery Order colour carId tires Customisations airConditioner mediaPlayer Extras paymentMethod totalPrice Payment
52. id status shippingAddress estimatedDelivery Order colour carId tires Customisations airConditioner mediaPlayer Extras paymentMethod totalPrice Payment OtherObject
53. id status shippingAddress estimatedDelivery Order colour carId tires Customisations airConditioner mediaPlayer Extras paymentMethod totalPrice Payment Root entity + conceptual consistency boundary = Aggregate Aggregate root In your model OtherObject
55. "Should <some concept> be an aggregate, an entity or a value object?"
56. "Should <some concept> be an aggregate, an entity or a value object?" It depends
57. "Should <some concept> be an aggregate, an entity or a value object?" on the model It depends — Some DDD practitioner, probably
58. find order by id find orders by status persist an order Order (aggregate)
59. find order by id find orders by status Persistence actions needed by the domain persist an order Order (aggregate)
60. find order by id find orders by status Persistence actions needed by the domain Aggregates that need direct access + set of persistence actions needed by the domain = Repository persist an order Order (aggregate)
61. = Repository OrderRepository + findById(id) + findAllByStatus(status) + store(order) Aggregates that need direct access + set of persistence actions needed by the domain
62. Domain Infrastructure
63. What if a responsibility from the model doesn't naturally fit an entity, aggregate or value object?
64. "Sometimes, it just isn't a thing" Domain-Driven Design - Eric Evans
65. Order (aggregate) Customer (aggregate) FinancingTerms (value object) Financing a car MonthlyPayment (value object)
66. Order (aggregate) Customer (aggregate) FinancingTerms (value object) Financing a car ? MonthlyPayment (value object)
67. Order (aggregate) Customer (aggregate) FinancingTerms (value object) Financing a car MonthlyPayment (value object) FinancingQuoteService ⇒ = Domain service Operation that stands alone in the model, without encapsulating state
68. Strategic design
69. Strategic design Tactical design
70. Combine strategic and tactical design!
71. Where do we go from here?
72. Next steps 1. Run away from the so-called "DDD lite" 2. Start with either: - Domain-Driven Design Distilled (Vaughn Vernon) or Domain-Driven Design Quickly (Abel Avram and Floyd Marinescu) 3. Watch the talk "7 Reasons Why DDD Projects Fail" (Greg Young) <vimeo.com/13824218> 4. Make your fundamentals understanding solid, do not rush it - Domain-Driven Design aka The Blue Book (Eric Evans) or Learning Domain-Driven Design (Vlad Khononov) 5. Practice modeling and coding - Don't use AI for that, frustration is important for learning 6. Go deeper: - Learn EventStorming (Alberto Brandolini) and other techniques for domain discovery and modeling - Read Implementing Domain-Driven Design aka The Red Book (Vaughn Vernon) - Learn event-sourcing (and CQRS) - Read CQRS Documents (Greg Young) - Read Event-Driven <event-driven.io> (Oskar Dudycz) - Read Architecture for Flow (Susanne Kaiser)
73. Go ahead and practice!
74. Thank you! @talyssonoc talysson.com @codeminer42 codeminer42.com