Lesson 0036 · Master Designer · Module 3

Isolation vs Integration

Isolated parts evolve independently; integrated parts stay consistent. The bounded context is the master's unit of this trade: isolation where meanings differ, integration where they can't.

Mission tie-in: the second Evolution Trade-Off — lesson 0009's boundaries, now at the scale of whole contexts and their shared meanings.

Knowledge: the context is the unit

Isolation — a context owns its model, its schema, its vocabulary. It evolves at its own speed; other contexts can't break it, and it can't break them. Cost: duplicated concepts across contexts (lesson 0028's duplication — but here it's earned: the "customer" in sales and the "customer" in support are genuinely different knowledge).

Integration — contexts share a model, a schema, an API. Consistency is guaranteed; divergence is impossible by construction. Cost: change amplification — one context's change ripples through all the others (lesson 0006 at system scale).

The deciding test is meaning, not overlap. When two teams use the word "order" to mean the same thing with the same rules, integration is honest. When their rules differ — sales' "confirmed order" vs warehouse's "picking order" — they are two concepts wearing one name, and forcing a shared model means every change negotiates the difference forever.

# integration where meaning is shared: a contract both sides truly share
class OrderConfirmed(Event):      # both contexts agree on this fact
    ...

# isolation where meaning diverges: each context owns its vocabulary
# sales.Order has "confirmed", warehouse.PickingOrder has "ready to pick"
# they meet only through the event — the anti-corruption boundary

The instruments: bounded contexts (isolation drawn at meaning), an anti-corruption layer (the adapter that translates between two vocabularies — lesson 0008's Adapter at context scale), and shared kernels (the small, stable set of concepts that genuinely must be shared, integrated on purpose).

† The failure pattern is the "one true model": a single schema everyone must fit — integration by decree. It works until the first genuine divergence, then every change becomes a committee meeting (lesson 0033's coordination debt).

Field notes · what it looks like in real code

You see this	What it costs	The move
one table read by two teams’ services	Integration by schema: every migration is a negotiation.	One owner; the other consumes events.
a shared “core” package that only grows	The one-true-model, accreting by default.	Split it; keep only what both sides genuinely share.
a field named status2 or type_for_billing	One model bent to hold two meanings.	Two models, one translation at the seam.
an import from another context’s internals	The anti-corruption layer was skipped.	Route through the published contract instead.

Skill: same meaning or same name?

Sales' "order" and warehouse's "order" have different rules. This is:

Two contexts meet through events and a translating adapter. That adapter is:

A concept both contexts share with identical rules deserves:

Practice on your own code

Find two modules (or teams' code) that share a name for a concept. Write the rules each side holds for it. If the rules match — deliberate shared kernel or honest merge. If they differ — draw the bounded context line and the translating adapter.

Reveal: a meaning audit

"Invoice" in billing and "invoice" in reporting: billing holds the legal lifecycle; reporting holds the display data. The shared table forced every billing change through reporting's migrations. Split: billing owns the invoice lifecycle; reporting consumes InvoiceIssued events and owns its own projection. One table became two contexts, and the migration coupling died with the shared schema.

Your win

You can audit any shared concept for meaning, draw bounded contexts at the divergence, and integrate deliberately where meaning is truly one.

Read and watch deeper

Domain-Driven Design, Evans — ch. 14 "Maintaining Model Integrity": bounded contexts, shared kernels, anti-corruption layers — the originals.
"Bounded Context", Fowler — the concept and its signals.
Team Topologies, Skelton & Pais — context boundaries as team boundaries (Conway's law, lesson 0033).
Watch: ArjanCodes YouTube — search "bounded context".
Next: lesson 0037 — Correctness vs Delivery Speed.
Reference: Trade-offs — isolation vs integration; Patterns — anti-corruption layer; glossary — bounded context, shared kernel.

Bring your shared-schema pain points to your agent-teacher and draw the context lines together.

Mark lesson complete