From Domain Boundaries to Software Architecture
summary
Shows how to find concrete service boundaries by running Event Storming, then validating flows with Domain Message Flow Modelling and locking decisions with a Bounded Context Canvas. Maps from an e‑scooter example (search, ride, ride completion) and a car pickup/dropoff case to reveal misplaced responsibilities and hidden messages. Uses reference scenarios, iterates boundaries, and measures coupling with the heuristic “coupling pain = strength × volatility × distance.” Demonstrates merging or splitting subdomains (fixed‑asset sales merged then split) until team autonomy and fast flow become realistic.
AI-written summary · about
chapters (21)
- 0:00Introduction
- 2:08Loosely coupled architecture
- 6:28Domain boundaries with event storming
- 10:21Event storming basics
- 13:08Clustering events into subdomains
- 16:42Refining domain boundaries
- 19:29Feedback from workshops
- 20:34Domain message flow modeling
- 24:05Validating boundaries with modeling
- 29:07Case study: fixed asset module
- 31:54Role play demo
- 33:20Bounded context canvas
- 38:15Analyzing bounded context
- 40:24Iterative refinement
- 42:07Collaboration and evolution
- 44:00Q&A
- 45:23Documentation with canvas
- 47:19Event frequency in storming
- 50:08Iterating after code
- 51:53Embracing modeling mistakes
- 53:39Closing remarks
related talks
40mFrom Domain Boundaries to Software Architecture
47mGetting modules right with Domain-driven Design
50mIt's All About the Domain, Honey - Domain-Focused Architecture with DDD
47mArchitecture for Flow with Wardley Mapping, DDD, and Team Topologies
39mFinding System Boundaries with Domain Storytelling
54mDomain-Driven Design and Team Topologies for Product-led Organizations
52mCarving Microservices out of the Monolith with Domain Storytelling
41mArchitecture for Flow with Wardley Mapping, DDD, and Team Topologies