Bounded Context — How to Modularize a System in a Few Steps
summary
Describes a concrete method to modularize a monolith into business-technical bounded contexts using EventStorming to find process boundaries, mapping system-level message flows, and then applying five decomposition heuristics: process state changes, change frequency/autonomy, single source of truth for availability, language differences, and reuse (for example separating pricing and payments contexts). Presents artifacts to produce (Miro maps, sequence diagrams, context contracts), guidance on where to expose inputs/outputs, and explains how these splits reduce cross-area changes and speed future feature rollout.
AI-written summary · about
chapters (15)
- 0:00Introduction
- 2:52Bounded Context
- 7:31Benefits of Bounded Contexts
- 10:45Problems without Bounded Contexts
- 13:38Starting system modularization
- 17:31Business process mapping
- 21:53Decomposition techniques
- 24:24Process division into contexts
- 25:51Autonomy and changeability
- 28:39System knowledge sources
- 31:51Organizational language differences
- 35:25Functionality reusability
- 37:53Combining techniques in practice
- 40:01Matias's goal for Bounded Contexts
- 41:06Summary and Q&A
related talks
39mFrom Domain Boundaries to Software Architecture
51mDissecting Bounded Contexts -
42mBounded Context: Keep It Simple!
51mModularization: Foundation of Microservices and Monoliths
48mExperiences scaling a modular monolith to microservices using the 4+1 views
48mModularization — It Was Supposed to Be Beautiful but Turned Out as Usual :(
55mCharting the uncharted: Discovering and evolving bounded contexts
47mBounded Contexts: Team Topologies and Architecture boundaries aligned