Where Platforms Fit: DDD Subdomains

Every platform team eventually gets asked “should we build this?” The most useful lens I’ve found comes from Domain-Driven Design’s three kinds of subdomain, applied the way Gregor Hohpe does in his writing on platform strategy.

The spectrum

Subdomain	What it is	Example	Platform stance
Generic	Solved problems that look the same everywhere	Cloud infrastructure, authentication, email delivery	Buy it. There’s no prize for building your own.
Supporting	Necessary, company-specific, but not what customers pay for	Deploy pipelines, service templates, observability setup, shared workflow tooling	This is where platforms belong — optimise the common processes every team repeats.
Core	What makes the business different	Product features, domain logic, the thing on the pitch deck	Product teams own it. The platform’s job is to keep their attention here.

The output of a platform isn’t the tooling. It’s reduced cognitive load: fewer decisions, fewer tickets and less yak-shaving for the teams delivering the core.

A quick test

Before investing in a platform capability, ask three questions:

1. Is every team rebuilding this themselves?
2. Is it genuinely not a differentiator?
3. Does no off-the-shelf tool fit well enough?

Three yeses means a supporting capability and a platform candidate. A “no” to the second means a product team should own it. A “no” to the third means buy and integrate.

An example

Imagine a company where several teams build AI assistants. Every new assistant needs a repo, a deploy pipeline, an evaluation harness and monitoring — and each team builds those from scratch. That scaffolding is supporting: needed, specific, not differentiating. A platform should offer it as a paved road. The conversation design and domain knowledge inside each assistant is core and stays with the teams. The underlying model hosting is generic: buy it.

The trade-offs

• The lines move. Yesterday’s core becomes tomorrow’s commodity (think of how many companies once ran their own mail servers). Revisit the map.
• “Supporting” is where platform teams over-build. The cure is treating developers as customers: research their pain first, and measure adoption rather than mandating usage.
• Agents change the audience. If AI agents are going to create services and run pipelines too, the supporting layer needs stricter contracts and better errors than humans ever demanded — see What Makes an AI Agent.

In practice

On a low-code workflow platform I led the UI for, this framing settled arguments quickly. Diagram rendering and forms were generic — we used well-supported open-source libraries rather than inventing our own. The workflow building blocks every use case needed were supporting, so we invested in reusable components and a catalogue of tested pieces. The network logic of each use case was core and belonged with the teams who understood it. The same thinking shaped Building a Graph Component Library: we built in-house only once it was clear the capability was specific enough, and costly enough to rent, to justify it.