Planes and Bounded Contexts

When I sketch a platform, I reach for two diagrams that look like they compete: management, control and data planes, and domain-driven design with its bounded contexts. They don’t compete. They answer different questions, and the design is clearest when you draw both.

Two lenses, two questions

	Planes	Bounded contexts
Splits by	when things change, and how often	business language and ownership
Management / control / data	people time / release time / request time	—
Answers	how does it run, what happens when part of it fails?	who owns what, and how do the parts talk?

Planes are an operational view. The management plane changes when people act, the control plane decides at release time, and the data plane executes on every request, so it must be the most resilient part. Bounded contexts are an ownership view: each has its own model and vocabulary (its ubiquitous language) and a team that owns it.

Contexts run vertically through the planes

The two lenses cross at right angles. A single bounded context usually spans all three planes. Take Release:

• Management: a “release” action, available only to the roles allowed to approve.
• Control: the pipeline, the eval gate, version records and feature flags.
• Data: the load balancer routing each request to the version the flags select.

One context, three planes. If you only draw planes, ownership disappears; if you only draw contexts, you lose sight of what runs on the hot path and what can fail without users noticing.

A worked example: a platform for shipping web services

Take an internal platform that lets product teams create, release and run web services. The bounded contexts are roughly:

• Service Scaffolding: templates, the CLI and portal, the service spec each team fills in.
• Release: pipelines, versions, feature flags, rollbacks.
• Environments: provisioning databases, queues and namespaces on request.
• Policy & Compliance: security baselines, data-handling rules, quotas.
• Traffic: gateways, routing, rate limits.

The context map is where the design gets interesting:

• The cloud provider is an upstream context with its own sprawling model. The platform’s infrastructure modules are an Anti-Corruption Layer, so product teams ask for “a database for orders”, not a page of provider settings.
• Legacy systems that services must integrate with are upstream too, and get the same treatment: a small adapter that translates their model into the platform’s language.
• The platform serves product teams as an open host service with a published language: the platform API, and the service spec every team writes in. Between the control and data planes, the published language is the configuration the runtime reads, versioned and cached so the data plane keeps working if the control plane is down.

And the subdomain split is the build-versus-buy decision (more in Where Platforms Fit: DDD Subdomains):

• Core: the business logic inside each service. Product teams build and own it.
• Supporting: scaffolding, release tooling, environment provisioning. The platform builds it, and keeps it simple.
• Generic: cloud hosting, identity, secrets, telemetry. Buy.

The short version

The planes tell you how the platform runs. DDD tells you who owns what and how the contexts talk. The anti-corruption layers are where the two lenses meet.

In practice I draw the planes first (they’re what an operator needs), then label each box with the context that owns it, then draw the arrows that cross context boundaries and ask of each one: is this a published language, or does it need an anti-corruption layer?