20 Years of Domain-Driven Design: What I’ve Learned About DDD

Eric Evans’ Domain-Driven Design (DDD) has shaped software development practices for over 20 years, providing a rich toolkit for tackling complex domains. But what truly works, and where do the pitfalls lie? This talk shares key lessons from two decades of applying DDD in real-world projects, offering practical advice for leveraging its most valuable concepts.

We’ll explore the importance of close collaboration with domain experts, techniques for effective modeling, and the often misunderstood role of bounded contexts in structuring systems. The talk also examines the evolving landscape of team collaboration, comparing DDD’s strategic design principles with newer approaches like Team Topologies.

Whether you’re new to DDD or looking to refine your practice, this session will help you focus on what matters most to successfully apply DDD in your projects

Transcript

1. 20 Years of Domain-Driven Design: What I’ve Learned About DDD Eberhard Wolff Head of Architecture https://swaglab.rocks/ https://ewolff.com/
2. What is DDD?
3. Big Picture Event Storming Bounded Context Core Domain Strategic Design More details Design-level Event Storming Tactical Design Stickies with Events to understand the domain and find bounded contexts. The focus of the project Collaboration between teams + bounded contexts Bounds for a domain model and a ubiquitous language Classes: Entities, aggregates, services, value objects … Add details to event storming (commands, systems …)
4. Some Personal Spotlights
5. My Start with DDD
6. How I Started with DDD •2006 •Primarily interested in tactical design •What kind of classes would you write?
7. Workshop with Eric Evans •2007 in Frankfurt •Start statement: Not all pieces of a system will have the same quality. •So either let it happen by chance …or steer the quality. •Simple but very powerful statement
8. Core Domain •Not all parts of a system are going to be equally refined. •Priorities must be set! •Boil the model down. •Find the Core Domain •Apply top talent to it!
9. Core Domain vs. XP •XP = Extreme Programming •XP: Aim for highest quality •XP: No compromise •Core Domain: Well, quality will be randomly distributed then.
10. Lesson Learned •DDD is more than rule to develop code – it is a holistic approach to software engineering •DDD is different things to different people
11. Big Picture Event Storming Bounded Context Core Domain Strategic Design More details Design-level Event Storming Tactical Design Different Thing for Different People
12. What to focus on?
13. That is no value. What do you think about how we migrate to DDD? We can change our software quicker. …. It enables features which is value for customers. So what is the value for customers? Seems fine. But what is the value for customers?
14. Seems fine. That is no value. What do you think about how we migrate to DDD? We can change our software quicker. But what is the value for customers? …. It only enables features = value for customers. So what is the value for customers?
15. Seems fine. That is no value. What do you think about how we migrate to DDD? We can change our software quicker. But what is the value for customers? …. It only enables features = value for customers. So what is the value for customers?
16. When have you spoken to a user the last time? What do they want improved? We do DDD. Not sure, a year ago? They are happy as it is. For any app I use, I know some potential improvements
17. When have you spoken to a user the last time? What do they want improved? We do DDD. Not sure, a year ago? They are happy as it is. For any app I use, I know some potential improvements
18. Domain-driven Design •It is not about the patterns. •The domain should be the focus of your development! •That means generating value for customers. •That means talking to customers and domain experts. •You can use all the patterns … …and still gain no value for customers.
19. Lesson Learned Let the Domain Drive the Design
20. Who actually does this?
21. Domain-driven Design •Domain-driven Design = knowledge crunching •Need customers, domain expert, development team… •Often they are not interested. •Often collaboration is hard •Software engineers, customers, and domain experts live in different worlds. •How do you engage with them?
22. What is Event Storming? •Event in the past •At least noun + verb •Verb in past tense •Write event on orange sticky Order accepted
23. Phase: Chaotic Exploration •Create as many events as possible
24. Phase: Enforce the timeline
25. Phase: Enforce the timeline
26. Phase: Identify Swim Lanes •Parallel activities Swimlane Invoicing Swimlane Delivery
27. Phase: Identify Pivotal Events •Afterwards the world is different Order accepted Parcel left warehouse Swimlane Invoicing Swimlane Delivery
28. Why Event Storming? •Truly collaborative! •Low barrier: write stickies! •Anyone can participate! •Highly parallel at the beginning •Unlike meeting with one person standing at a whiteboard.
29. Artefact vs. Process •Domain experts and customers collaborate with development team. •Ideally a fun experience. •Collaboration or artefact – what is more important? •Do we focus too much on the artefact?
30. Alternatives: Collaborative Modeling •E.g. domain story telling •Also facilitates collaboration •Even just a miro board / stickies and work in parallel might already help!
31. Lesson Learned •Collaborative modelling facilitates collaboration. •Is creating an artefact a secondary goal?
32. Bounded Context
33. Bounded Context Bounds Domain Model i.e. Code Ubiquitous Language
34. Order Process Invoicing Process Bounded Context Example Invoicing VAT Shipping Tracking Delivery Accept order Shopping Cart
35. Order Process Invoicing Process Bounded Context Example Customer e.g. billing address Product e.g. price Shipping Customer e.g. shipping address Product e.g. size Product e.g. marketing information Customer e.g. product preferences
36. Why is Bounded Context so Important? •Core pattern of Domain-driven Design •Limits the context of a ubiquitous language •Central to structuring systems into domain models •Also defines the scope of a team
37. Bounded Context: Three Implications Ubiquitous Language Domain Model Teams
38. Order Process Invoicing Process Bounded Context Model? Customer e.g. billing address Product e.g. price Shipping Customer e.g. shipping address Product e.g. size Product e.g. marketing information Customer e.g. product preferences Focus: Business Logic!
39. Product: price Product: size / weight Order Process Invoicing Process Bounded Context Ubiquitous Language? Invoicing VAT Shipping Tracking Delivery Accept order Shopping Cart Term: Invoice Term: Shipment
40. Order Process Invoicing Process Bounded Context Team? Invoicing VAT Shipping Tracking Delivery Accept order Shopping Cart Why can’t one team build all of this?
41. Bounded Context: Advice •Focus usually: Model / code •Does the ubiquitous language help for this? •Why would one team work on just one model?
42. Order Process Invoicing Process Bounded Context Model? Customer e.g. billing address Product e.g. price Shipping Customer e.g. shipping address Product e.g. size Product e.g. marketing information Customer e.g. product preferences
43. Order Customer What If We Build Data Modules? Product Customer orders a product Invoicing a customer for an order of products Delivering a product to a customer because of an order Everything depends on these models! Customer for invoice: SWAGLab GmbH Customer for delivery: Eberhard Wolff What does the uniform model look like?
44. Order Customer Data Modules: Autonomy Product Shipping Shipping can only do its job with three other models
45. Order Process Invoicing Process Highly Autonomous Models Shipping Customer for shipping Product for shipping Customer for invocing Product for invoicing
46. Bounded Context: Advice •Focus on functionality not data! •“Customer” is data – no great model •Focus on autonomy! •Model should include all necessary data •Maybe autonomous models are a better way to find good modules?
47. https://software-architektur.tv/2024/06/14/episode220.html
48. https://software-architektur.tv/2025/04/25/folge261.html
49. Lesson Learned •Bounded Context = ubiquitous language, model, team •Too many aspects makes Bounded Context complex •Focus on models / modules instead?
50. Integration?
51. Order Process Invoicing Process Bounded Context Integration? Invoicing VAT Shipping Tracking Delivery Accept order Shopping Cart Order can make it impossible to implement shipping. Order can make it impossible to implement invoicing. …if it provides no information about new orders. Upstream / downstream Order team should help Invoicing and Shipping Customer / Supplier
52. Bounded Context: Integration •Bounded Contexts lead to team dependencies. •Team dependencies must be dealt with on the organizational level. •Socio-technical: Technical structure leads to organizational response •Socio-technical was a thing in DDD >20 years ago.
53. Challenge •My experience: Hard to adapt •Complicated (8 patterns, 3 types of dependencies) •Not intuitive? •Only covers teams that work on Bounded Contexts
54. https://software-architektur.tv/2021/08/27/folge72.html
55. Team Topologies instead? •Not too complex •Intuitive (?) •Covers more team types than development teams
56. Team Topologies Order Processing Kubernetes / CI Team Delivery Optimization Invoicing Delivery XaaS Architecture Collaboration Facilitating XaaS
57. https://software-architektur.tv/2024/04/18/folge213.html
58. Lesson Learned •Strategic Design seems logical …but is limited and hard to adopt •Consider Team Topologies instead
59. Priorities?
60. Order Process Invoicing Process What is the Core Domain? Invoicing VAT Shipping Tracking Delivery Accept order Shopping Cart We differentiate with our excellent and timely shipping. What shall we focus on? Buy Export to SAP
61. Tactical Design Entity Value Object Domain Event Identity: a person Value: 2€, 2m Something has happened. Matters to domain experts
62. Tactical Design Entity Value Object Aggregate Factory Repository Domain Event Consists of Entities and Value Objects Aggregate Root ensures consistency Illusion of a collection of aggregates Creates complex value objects and aggregates
63. Tactical Design Entity Value Object Aggregate Factory Repository Service Domain Event Logic doesn‘t fit in Entities / Aggregates
64. https://software-architektur.tv/2024/05/03/folge214.html
65. https://software-architektur.tv/2024/05/31/episode219.html
66. Alternatives for Less Complex Systems •Transaction script: handles a single request from the presentation incl. database code. •Table model: Single instance handles business logic for all rows in a database table or view.
67. Order Process Invoicing Process Tactical Design Invoicing VAT Shipping Tracking Delivery Accept order Shopping Cart We differentiate with our excellent and timely shipping. Buy Export to SAP Tactical DDD Transaction Script Or some data mapper
68. Lesson Learned •Tactical Design is optional
69. Conclusion
70. Lessons Learned •Let the Domain Drive the Design! •Collaborative modelling facilitates collaboration. •Is creating an artefact a secondary goal?
71. Lessons Learned •Bounded Context = ubiquitous language, model, team •Makes Bounded Context complex •Focus on highly models / modules instead?
72. Lesson Learned •Strategic Design seems logical …but is limited and hard to adopt •Consider Team Topologies instead •Tactical Design is optional
73. https://software-architektur.tv/tags.html#Domain-driven%20Design
74. WIR SUCHEN MITGESTALTER:INNEN swaglab.rocks/karriere
75. DRINK A VIRTUAL COFFEE WITH ME! https://calendly.com/eberhard-wolff-swaglab/
76. Download here! Send email to jax2025@ewolff.com Slides + more Powered by Amazon Lambda & Microservices Email address logged for 14 days, wrong addressed emails handled manually