Strategic Design

Segregated Core means physically moving the core domain's code into its own module, cutting its ties to generic/supporting code, so the highest-value logic is easy to find, protect, and invest in — at the cost of a real refactor with real short-term pain.

The workshop likely had no active facilitator keeping everyone working on one shared timeline together; without someone managing turn-taking and periodically walking the whole group through what's been built, a big mixed group splits into disconnected sub-groups that never reconcile.

The company's special feature stops improving fast while its 'boring' internal tools get overpolished. Customers notice the product isn't getting better where it matters, while the org's best people are working on something invisible to customers. The fix isn't hiring more people — it's moving the senior people to the right subdomain.

Split when the team can't reason about the whole model at once, parts change for unrelated reasons, or sub-teams have informally formed. Splitting too early wastes effort on a premature boundary; splitting too late lets coupling keep growing.

Sometimes it's genuinely cheaper for two teams to solve the same small problem twice than to coordinate an integration - that's Separate Ways. Partnership is the opposite: two teams whose goals are tightly linked agree to plan together and succeed or fail together.

Classifications aren't permanent — watch for signs that something quietly became a big reason customers stay or leave, then treat it that way. Actually changing it usually means moving your best engineers there, rebuilding the messy code more carefully, and reorganizing who owns it — which is slow and disruptive, not a quick relabeling.

Forcing every team to use the exact same words for everything doesn't scale — different departments genuinely mean different things by the same word, and a single glossary either becomes too vague to be useful or turns into a slow, contested bottleneck. Better to keep each team's language consistent internally and manage translation only where teams actually need to talk to each other.

Yes, it's usually worth doing gradually — renaming things to match how people actually talk saves confusion for years to come. Do it in small, safe steps (rename in code first behind the old database names, or use views/aliases) rather than one giant risky change all at once.

A context map isn't just a snapshot — you can draw two versions, 'as-is' and 'target,' and use the gap between them to plan the sequence of changes, both technical and organizational, that gets you from one to the other over months or years.

The clusters and pain points found in an Event Storming session feed into deciding which parts of the business are the special, valuable core (worth custom-building) versus generic parts (worth buying off the shelf), and into drawing the map of how different teams' models relate. You'd skip the workshop if the domain is already well understood and documented, since the exercise mainly earns its cost by surfacing hidden disagreements.