Domain Driven Design in practice - how to draw your domain boundaries IRL
summary
After merging four Nordic marketplaces into one company, the team uses domain driven design to redraw boundaries, iterating in Miro/mirror and on the whiteboard, interviewing stakeholders one‑on‑one and running “info time” sessions per team (5–12 people). The concrete outputs are a published domain map, a staffing plan that creates 1 new team (started), splits an overloaded team, and defers one domain; decisions target a 1–2 year rollout and aim to keep one team per domain while tracking evolving ownership.
AI-written summary · about
chapters (18)
- 0:00Domain Driven Design intro
- 5:05What DDD is and why it matters
- 9:21New real estate vertical
- 11:30DDD as art not science
- 18:59First mental model
- 21:47Forcing stakeholder engagement
- 26:13Final domain map
- 29:10Season one recap
- 31:45Explaining to big boss
- 35:14Tailoring for tech leads
- 37:43Presenting to business
- 41:15Highlighting organizational implications of the map
- 44:25Info time with tech
- 46:39Surprise character
- 49:06Season two recap
- 50:13Epilogue
- 51:37Director's cut
- 54:06Main takeaways
related talks
54mDomain-Driven Design and Team Topologies for Product-led Organizations
38mDomain-Driven Design & Team Topologies Hands-on
56mMicroservices and Domain-Driven Design — The Strategic Parts
01h 04mDomain Driven Design: The Good Parts
38mDomain-Driven Design: Hidden Lessons from the Big Blue Book
47mGetting modules right with Domain-driven Design
57mDomain-Driven Design in Productland
59mDomain Driven Design: The Good Parts
