You are decomposing a monolith. How do you find the boundaries using evidence rather than opinion?
Show the full answer Hide the answer
What is being tested
Whether you use evidence about what the system is, rather than a data model or an org chart.
The three sources of evidence
1. Language. Listen for a word whose meaning changes. "Customer" in sales is a prospect with a pipeline stage; in fulfilment an address and preferences; in finance a payment method and credit position.
These are different concepts sharing a name, and each is its own bounded context. Forcing them into one model produces an entity with sixty fields of which each consumer uses eight, which nobody can change without coordinating with everyone.
2. Change correlation. Analyse the last several hundred commits: which files and packages change together? Clusters that consistently change together belong together.
This is the strongest signal because it describes the system's actual behaviour rather than anyone's intent — and it frequently contradicts the architecture diagram.
3. Data access. Which code touches which tables? Clusters with few crossings are natural boundaries; the crossings are the coupling you will have to resolve.
The technique for finding them quickly
Map the business events in sequence with domain experts and engineers in one room — what happens, in what order, triggered by what.
The clusters of events that belong together, and the points where the language changes, are the context boundaries. Far faster and more accurate than modelling data, and it produces boundaries derived from the domain rather than from the current schema.
What the boundaries must satisfy
Each context owns its data and can complete a business action end to end. If completing an action requires three contexts synchronously, the boundary is wrong.
The extraction order
Read-only stateless components first (reversible, no ownership to resolve), then components with clearly owned data, then those with a forcing reason, then the tangled core last — and possibly never.
The hard part is always data: assign ownership, route all foreign access through the owner's interface, then physically separate. The database can stay shared for a long time while the access is not.