From Domain Boundaries to Software Architecture
summary
Claim: mapping which business concepts change together produces actionable, loosely coupled architecture. The process uses Event Storming, then refines boundaries with Domain Message Flow Modelling and consolidates responsibilities on a Bounded Context Canvas. Teams uncover surprising facts (one workshop surfaces 180 process steps and 15+ candidate subdomains), run scenario-driven message diagrams, measure coupling (strength × volatility × distance), iterate with code probes, and end up with a concrete first-step implementation plan rather than a final architecture.
AI-written summary · about
chapters (8)
- 0:00Introduction
- 2:15Loosely coupled architecture benefits
- 7:30Event storming for domain flows
- 15:57Refining domain boundaries
- 20:12Domain message flow modeling
- 29:46Service roles with bounded context
- 35:01Iterative DDD process overview
- 38:08Mindset shifts for modeling
related talks
54mFrom Domain Boundaries to Software Architecture
47mGetting modules right with Domain-driven Design
47mBlending Product Thinking with Architecture
46mMaster Software Architecture: From Simplicity to Complexity
41mArchitecture for Flow with Wardley Mapping, DDD, and Team Topologies
40mAdaptive Socio-Technical Systems with Architecture for Flow
55mDomain Driven Design in practice - how to draw your domain boundaries IRL
40mArchitecture Modernization with DDD