Smart teams rarely build the wrong thing because they lack skill, effort, or good intentions. And yet, projects can move forward with confidence, decisions can seem perfectly reasonable, and teams can still end up building something very different from what was actually needed.
So where does it go wrong?
In this hands-on workshop, we won't start by teaching Domain-Driven Design concepts. Instead, we'll take a real project from the room and put our own understanding of it to the test.
You'll work with the same information, make concrete decisions about what to build, prioritise, measure or invest in and see where those decisions take the project.
Only then will we step back and examine what happened.
Together, we'll explore what this experience can teach us about Domain-Driven Design: why making our understanding of the domain explicit matters, how language and models shape the software we build, and how DDD can help teams discover important differences before they become expensive.
We'll also explore the other side of the question: when is this level of domain modelling worth the investment and when is DDD simply not the right tool?
This is not a compressed DDD course. It's an opportunity to experience one of the problems DDD is designed to help us work with before exploring the larger territory behind it.
No previous DDD knowledge is required.
You'll leave with a different lens for looking at software projects, a clearer understanding of why Domain-Driven Design can matter, and a question worth taking back to your team:
What are we treating as obvious that might be worth examining more closely?

Beginner-friendly, hands-on workshop. No previous DDD knowledge required. Best suited for software engineers, architects, product people and business analysts. Preferred duration: 2 hours. This would be the first public delivery of the workshop in its current format.