Domain-Driven Design and Team Topologies for Product-led Organizations
summary
Cross-functional workshops using event storming (orange post‑its on a timeline, Miro board) reveal concrete domain boundaries and failures such as a data‑cleansing step that corrupts downstream UX and a duplicated API reuse that two teams implement together over dinner. Apply Team Topologies patterns and the independent service heuristics from GitHub to test candidate boundaries, honor cognitive load (teams of 5–9), and change interaction modes. Use the core domain chart to prioritise where to create autonomous product teams versus refactor large monoliths.
AI-written summary · about
chapters (13)
- 0:00Start
- 6:55The Best Product Ideas Come From the Whole Team Event Storming
- 17:40Exploring Opportunities
- 20:53Domain Roles
- 24:26Team Topologies: A Toolkit for Organizing Teams for Fast Flow & Empowerment
- 26:48Team Topologies: What is a team, what is the cognitive limit?
- 29:37Team Topologies Interaction Modes
- 32:36Disempowering Funding Model: Platforms are unded by Verticals
- 37:35Core, Supporting and Generic Domains
- 38:12Evolving the Strategic Domain Landscape
- 39:21Industry Example: Hidden Domain, Experiences Industry
- 47:21Modernization Core Domain Charts
- 50:52Avoid Big Reorgs. Build a Sensing Organization
related talks
49mDomain-Driven Design & Team Topologies For Product-led Organizations
38mDomain-Driven Design & Team Topologies Hands-on
57mDomain-Driven Design in Productland
55mDomain Driven Design in practice - how to draw your domain boundaries IRL
38mDomain-Driven Design: Hidden Lessons from the Big Blue Book
41mDomain-Driven Design: Hidden Lessons from the Big Blue Book
41mEfficient Domain-Driven Design: An Introduction to Event Storming
47mArchitecture for Flow with Wardley Mapping, DDD, and Team Topologies