Skip to content

Bounded Context or Domain Boundary Review

Domain-modelling review — instantiates Organization–Artifact Topology Alignment

Draws the boundaries the problem domain itself implies — where the language, rules, and models change — to define the architecture the artifact should have, independent of who currently builds it.

The other two mapping mechanisms show what is — the artifact's coupling, the organization's communication. Bounded Context or Domain Boundary Review supplies what should be: the boundaries the domain itself implies, drawn from where the language and rules change rather than from the current code or the current org. Its defining move is to be deliberately blind to both the artifact and the org chart, so it produces an uncontaminated reference — the desired architecture — against which any accidental mirroring of the organization can be recognized as accidental.

Example

An insurance company keeps tripping over one word. Customer means a policyholder in underwriting, a claimant in claims, and a payer in billing — and the shared Customer object that tries to serve all three has become a tangle nobody dares touch. A Bounded Context or Domain Boundary Review maps where the ubiquitous language actually changes and finds three distinct contexts — Policy, Claims, Billing — with a context map showing how each translates Customer at its edge. It also marks two hard external boundaries the domain imposes: the regulator's jurisdiction line and the third-party actuarial vendor's data boundary. The output is a desired architecture intent — three bounded contexts with explicit translations — that the refactoring and team-design mechanisms then steer toward. Crucially, this target was derived with no reference to which team owns what today.

How it works

What distinguishes it from the artifact and org reviews is where it looks:

  • Follow the language — boundaries fall where the ubiquitous language and the domain invariants change, not where the code or the reporting lines fall.
  • Draw a context map — name each bounded context and the relationship at every seam (shared kernel, customer/supplier, anti-corruption layer).
  • Mark external boundaries — vendor and jurisdiction lines the domain forces on the design regardless of internal structure.
  • Stay org-blind on purpose — exclude the current team layout so the target is a genuine reference, not a rationalization of the status quo.

Tuning parameters

  • Boundary heuristic — language-change versus data-ownership versus rate-of-change. Each cuts the domain differently; pick the one that matches what actually varies.
  • Context-map fidelity — how many relationship types to model at each seam. Richer maps guide integration better but take longer to build and agree.
  • External-boundary scope — how far to model vendor and jurisdiction lines. Wider scope captures compliance seams but expands the effort.
  • Abstraction level — a few strategic contexts versus many tactical ones. Coarse is actionable; fine risks analysis paralysis.
  • Org-blindness discipline — how strictly to exclude today's team layout, the dial that decides whether the target is a real reference or the org chart in disguise.

When it helps, and when it misleads

Its strength is that it yields a target uncontaminated by the current organization, which is the only way to tell a domain-required seam from one the org imposed. Without it, every refactor risks reshuffling Conway's imprint into a new arrangement that is equally org-shaped.

Its failure mode is that domain boundaries are judgment calls, and the judgment can be bent to fit the incumbents — drawing "contexts" neatly around today's teams and calling the result domain-driven. The classic misuse is exactly that reverse-engineering: inferring the domain from the existing org so a planned reorganization looks principled. The discipline that guards against it is to derive boundaries from the ubiquitous language and from domain experts who don't own the code, and to sanity-check that the proposed contexts would look the same if the company were reorganized tomorrow.[1]

How it implements the components

Bounded Context or Domain Boundary Review fills the should-be side of the archetype — the reference components, not the as-is maps or the levers that act on them:

  • domain_model_boundary_map — its primary output: the context map of where the domain's language and rules change.
  • desired_architecture_intent — the target architecture that the boundary map implies, stated so downstream mechanisms can steer toward it.
  • vendor_or_jurisdiction_boundary_map — the external boundaries the domain imposes, which any internal structure has to respect.

It defines the target but does not move toward it: the architecture_refactoring_option_set belongs to Artifact Boundary Refactor and the team_topology_design_option_set to Inverse Conway Design Intervention.

Notes

This is the only reference in the archetype that is independent of both the artifact and the organization, which is what makes it load-bearing: it is consumed as a target by the refactor and team-design mechanisms rather than acted on directly. It also goes stale when the domain itself shifts — a new product line, a new regulatory regime — so a target that was right two years ago can quietly become the wrong thing to steer toward.

References

[1] Bounded Context and the Context Map are strategic-design patterns from Eric Evans's Domain-Driven Design; a bounded context is the scope within which a single model and its ubiquitous language hold consistently. The patterns are correctly applied only when the boundaries are read off the domain language, not retrofitted to the current team structure. ↩