When you're carving a large, tangled domain model into bounded contexts, what concrete signals ('seams') tell you where one context should end and the next begin?

## Why seams are read, not drawn Carving a large, tangled domain model into bounded contexts is not a mechanical exercise you can do from a whiteboard alone - it requires reading specific signals ('**seams**') in how the business actually behaves, because a wrong boundary is expensive to walk back later. Five signals are the most reliable in practice. ## The five signals 1. **Language divergence** - the first and most direct signal. When you sit with two groups of domain experts and notice that a shared-sounding term picks up different attributes, different lifecycle, or a genuinely different meaning depending on who's speaking - '**Customer**' meaning a person with email preferences to one group and a person with a shipping address and credit terms to another - that's strong evidence of a seam. The test isn't whether the word is literally the same; it's whether the two groups could sit in the same meeting and use the term interchangeably without confusion. If they can't, there are two models hiding behind one word. 2. **Ownership by business capability** - the second signal. Organizations tend to organize around end-to-end capabilities - Order Fulfillment, Customer Support, Pricing - and a group that owns a capability end-to-end, making its own decisions about how that capability works, is a strong candidate for a bounded context boundary. This isn't about following the org chart blindly (a purely political signal can mislead you), but about recognizing where a coherent slice of business responsibility already exists. 3. **The transactional consistency boundary** - the third, and often the most rigorous. Ask: which pieces of data must be updated together, atomically, in the same instant, or the business considers the result corrupted? An account balance and a pending transaction amount that must always sum correctly represent one invariant, and one invariant should be enforced by one context, typically inside one transaction. Conversely, if two pieces of data are allowed to be inconsistent for a while - a shipment's tracking status can lag an order's status by seconds or minutes without anyone considering the system broken - that tolerance for eventual consistency is itself evidence that a seam exists between them, because they don't share the same invariant. 4. **Rate and reason for change** - the fourth signal. Concepts that change together, for the same underlying business reason, tend to belong together; concepts that change independently, for unrelated reasons, are candidates for separate contexts. Pricing rules change because of business strategy and competitive positioning; shipping regulations change because of carrier contracts and customs law. Even if both concepts currently live in the same class, their volatility sources are unrelated, which is a leading indicator they'll eventually need to move independently, and better to plan the seam before that pressure forces an urgent, panicked split. 5. **Legal, regulatory, or compliance boundaries** - the fifth signal, and the one that is external, structural, and non-negotiable. Payment card data falling under PCI-DSS scope, for instance, forces a hard isolation boundary around payment processing regardless of how convenient it would be to keep it colocated with everything else - the boundary is imposed by an authority outside the domain model's own logic. ## Surfacing them collaboratively In practice, these signals are surfaced collaboratively, not derived by an architect alone at a whiteboard. **Event Storming** is the most widely used technique: domain experts and engineers narrate the business as a sequence of past-tense domain events ('Order Placed', 'Payment Captured', 'Shipment Dispatched') on sticky notes along a timeline, without pre-committing to any module or service structure. As the timeline fills in, events naturally cluster: - events that share vocabulary, share an owning actor, and sit close together in time tend to belong to one cohesive context; - visible gaps in vocabulary or a shift in who's narrating the story mark candidate seams. ## Getting it wrong, in both directions The failure mode of getting this wrong shows up two ways in production. | The mistake | What you get | |---|---| | Draw the boundary too coarse (missing a real seam) | you get the 'shared, ever-growing model' problem - unrelated concerns tangled together, breaking each other on every change | | Draw it too fine, or in the wrong place - e.g., splitting a single atomic invariant across two contexts that then need constant synchronous cross-context calls to stay correct | you get chatty, fragile, hard-to-reason-about integration that's often worse than the monolith it replaced | The practical discipline is to prioritize the consistency-boundary and language-divergence signals as the most trustworthy, and treat org-chart alignment as something to verify against those, not something to assume is already correct.