From Domain Boundaries to Software Architecture
summary
Claims a repeatable path from messy monoliths to loosely coupled modules using Event Storming, Domain Message Flow Modelling, and the Bounded Context Canvas. Workshops map business events, produce visual message-flow diagrams, and run quick refinement cycles; a coupling “pain” = strength × volatility × distance flags expensive dependencies. Examples include scooter rentals, online orders and fixed‑asset sales where teams merge or split boundaries, adjust ownership, and produce deployable first increments that reduce coupling and speed delivery.
AI-written summary · about
chapters (8)
- 0:00Introduction and speakers
- 2:14Talk overview and goals
- 8:16Finding domain boundaries with event storming
- 15:56Refining domain boundaries
- 28:18Domain message flow modeling
- 30:05Validating with bounded context canvas
- 33:41Iterative DDD process overview
- 36:12Final thoughts and Q&A
related talks
42mBounded Context — How to Modularize a System in a Few Steps
47mGetting modules right with Domain-driven Design
44mArchitecture for Flow - Wardley Mapping, DDD, and Team Topologies
47mDomain-Driven Design: A Complete Example
51mDomain - Driven Transformation
50mHow EventStorming Transformed Our Domain Modeling Process
47mArchitecture for Flow with Wardley Mapping, DDD, and Team Topologies
31mHow EventStorming Transformed Our Domain Modeling Process