Failures and learnings during the adoption of DDD

Domain-Driven Design is no silver bullet and does not solve any problem in magical ways. The challenges and complexity that we try to tackle with DDD are hard and there is no easy way out. Nevertheless there is a growing popularity and appreciation for the topic in the market which may lead to overly ambitious expectations and eventually to disgruntled expectations.

The speaker of this talk has been working with Domain-Driven Design for the last 17 years on many software systems and this talk is about my experiences with failure. Believe me: I have failed a lot but there is always a chance to learn. The talk aims at giving you a chance to learn from the mistakes of me as an consultant and of the teams / organizations I have been working with.

The talk will address topics like:
- Domain-Driven Design in the waterfall
- Ignorance for code (aka only focus on strategic design)
- Overusage of patterns for their own sake
- Cultural implications
- Cargo Culting
- Developer Experience
- Rare availability of domain experts
- Dealing with established modeling techniques / methods
- Ignorance for the definitions / meaning of heuristics and patterns

This talk aims at providing you with a sensibility for potential hazards when you try to adopt DDD for your team and your organization and will contain only real-worlds scenarios that have actually happened. Each described failure will also come with a learning on what to do better.

Transcript

1. Failures and learnings during the adoption of DDD MICHAEL PLÖD FELLOW
2. Michael Plöd Fellow at INNOQ Mastodon (or Twitter): @bitboss@mastodon.social LinkedIn: https://www.linkedin.com/in/michael-ploed/ Current consulting topics: • Domain-Driven Design • Team Topologies • Transformation from IT Delivery to digital product orgs Regular speaker at (inter-)national conferences and author of a book + various articles
3. Get my DDD book cheaper Book Voucher: 7.99 instead of (min) 9.99 http://leanpub.com/ddd-by-example/c/speakerdeck
4. I have failed a lot with DDD …
5. … and learned so much on this path …
6. … which was valuable
7. Failure #1 Ignorance for culture
8. Domain Subdomain Subdomain Bounded Context Tactical Patterns Aggregate, Entity, Value Object, Repository, Service, Factory Bounded Context Tactical Patterns Aggregate, Entity, Value Object, Repository, Service, Factory Bounded Context Tactical Patterns Aggregate, Entity, Value Object, Repository, Service, Factory Strategic DDD Domain Subdomain Bounded Context Context Map Tactical DDD Aggregate Entity Value Object Repository Service Factory
9. Those are just two aspects of Domain Driven Design
10. ATTITUDE DDD is a culture for domain modeling Strategic DDD Domain Subdomain Bounded Context Context Map Tactical DDD Aggregate Entity Value Object Repository Service Factory
11. DDD is a culture for domain modeling Strategic DDD Domain Subdomain Bounded Context Context Map Tactical DDD Aggregate Entity Value Object Repository Service Factory Explicit->implicit Continuous Learning Evolutionary Design Compare Models Language Psychological Safety Collaboration Low entrance barrier
12. When the foundation is gone you no langer have a solid base for modeling
13. Failure #2 DDDfall
14. The promise: Time to market with DDD Photo by Campful on Unsplash
15. We aRE AgILe wE aRE dOIng SCrUM Photo by Kelly Sikkema on Unsplash
16. Photo by Michael Plöd
17. DDD in a waterfall Photo by Ingo Doerrie on Unsplash
19. https://github.com/ddd-crew/ddd-starter-modelling-process
20. Failure #3 Lack of domain experts
21. No access to domain knowledge means No Domain Driven Design
22. Domain Expertise can sometimes be hidden in interesting spots that you don’t expect
23. Failure #4 Uncollaborative Modelling
24. Source: https://amplitude.com/blog/journey-to-product-teams-infographic
25. Source: https://amplitude.com/blog/journey-to-product-teams-infographic
26. Use collaborative modeling methods with a low entrance barrier Image for example mapping taken from: https://openpracticelibrary.com/practice/example-mapping/ Image for user story mapping taken from: https://www.hanssamios.com/dokuwiki/how_do_we_build_and_maintain_context_when_all_we_have_is_a_backlog_list
28. Failure #5 Rebranding
29. „Basically we’ve been doing DDD for ages already“
30. Object Oriented Analysis and Design was nouns irst
31. EventStorming is verbs irst
32. Failure #6 Code allergy
34. Mind the code probe!!!
35. But we need a good design irst
36. Photo by Michael Plöd
37. Go for code early, prototype, fail, prototype again, fail again, re ine the prototype, re lect your strategic design based on those learnings, learn, go to prod, learn, refactor the code, learn, learn, learn, learn, …
38. Failure #7 Pattern stubbornness
39. Someone: „You are only doing true DDD if you strictly stick to hexagonal architecture and the tactical patterns everywhere, no exceptions!“
40. A gentle comment…
42. Mind the purpose … A Bounded Context is a boundary for a model expressed in a consistent language tailored around a speci ic purpose
43. If the purpose of a Bounded Context doesn’t call for some of the patterns, don’t use them. Understanding this, acknowledging it and designing your software accordingly is so much more about DDD than blindly sticking to some patterns because they were in a blue book (which is amazing, no diss!).
44. Failure #8 Silver Bullet Thinking
46. This book is important, a (probably) timeless classic in IT literature. But it’s not a bible and shouldn’t be treated like one.
47. Domain Driven Design is not a silver bullet
48. - George E. P. Box - All models are wrong, but some are useful
49. Failure #9 Terminology ignorance
50. Some IT conference Registration of visitors Lunch planning Printing of badges Room planning Selling tickets Handling of payments
51. YOU at some IT conference Registration of visitors Lunch planning Printing of badges Room planning Selling tickets Handling of payments
52. Don’t Repeat Yourself
53. YOU at some IT conference Registration of visitors Lunch planning Printing of badges Room planning Selling tickets Handling of payments
54. Bounded Context A Bounded Context is a boundary for a model expressed in a consistent language tailored around a speci ic purpose
55. This has no purpose at all and the language is also not speci ic here
56. Maybe those are interesting bounded context candidates? Event Management Badges Ticket Sales
57. Failure #10 Developer (miss)experience
58. https://github.com/ddd-crew/ddd-starter-modelling-process
59. https://github.com/ddd-crew/ddd-starter-modelling-process You won’t achieve quick learning cycles with a horrible developer experience
60. Failure #11 Hesitance to kill darlings
61. A story of a brilliant manager during a 5 day offsite workshop series
62. Day 1: EventStorming Photo by Michael Plöd
63. Day 2: (Sub)Domains Photo by Michael Plöd
64. Day 3: Bounded Contexts Photo by Michael Plöd
65. Day 4: Trashing Bounded Contexts Photo by Jilbert Ebrahimi on Unsplash
66. Manager: „this looks totally different … where are yesterdays Bounded Contexts“ Team: „we learned something and trashed them for another design“ Day 5: Questions
67. Day 5: A toast to the dead contexts !
68. Get rid of unsuitable designs
69. Failure #12 Fullblown DDD
70. Let’s do a DDD project and apply everything.
71. An interesting path Photo by Michael Plöd
72. To Hekla, one of Icelands most dangerous volcanos Photo by Michael Plöd
73. Don’t do full blown DDD just for the sake of it. Just use the concepts that solve your problems. Photo by Michael Plöd
74. Get my DDD book cheaper Book Voucher: 7.99 instead of (min) 9.99 http://leanpub.com/ddd-by-example/c/speakerdeck
75. Krischerstr. 100 40789 Monheim +49 2173 3366-0 Ohlauer Str. 43 10999 Berlin Ludwigstr. 180E 63067 Offenbach Kreuzstr. 16 80331 München Hermannstrasse 13 20095 Hamburg Erftstr. 15-17 50672 Köln Königstorgraben 11 90402 Nürnberg innoQ Deutschland GmbH www.innoq.com Thank you! Michael Plöd E-Mail: michael.ploed@innoq.com Socials: @bitboss@mastodon.social LinkedIn: https://www.linkedin.com/in/michael-ploed/ German version of Team Topologies incl. the Remote Team Interactions Workbook Translated by me Release through O’Reilly Germany in approx. November 2023