The Platform Relevance Gap

The first chapter of Domain-Driven Platform Engineering names something I’ve felt for years. Platforms provide capabilities, but they never fully reflect the realities of the domain they serve. There’s always a gap, and that gap is where friction lives.

How the gap shows up

The first wave of platform engineering gave us a lot: infrastructure automation, internal developer platforms, developer portals, golden paths, policy as code, observability stacks, cloud foundations. What’s missing isn’t another capability. The gap is relevance.

Left alone, the misalignment becomes visible over time as slower delivery, inconsistent implementations and rising operational risk: exactly the things DORA Metrics would show.

Relevant, not feature-rich

The reframe is to ask how a platform can be more relevant rather than more feature-rich, by building domain knowledge directly into its capabilities. The approach is incremental and layered:

1. Find where domain friction exists.
2. Elevate common patterns into domain-aware capabilities.
3. Shift non-differentiating complexity back into the platform, so teams carry less cognitive load.
4. Let domain teams spend more and more of their time on what genuinely differentiates the business.

Success is measured not by what the platform provides, but by what it enables.

It’s Hohpe’s idea that platforms belong in supporting domains (Where Platforms Fit: DDD Subdomains), made operational, and the antidote to platforms built in one shot that nobody uses (Growing a Platform: Breadth, Depth and Gear Shifting).

Governed autonomy

The balance is between enterprise standards and domain specifics: give teams enough standardisation to be safe and enough freedom to move.

The same rules for AI agents

The part I found most timely: the principles that help human developers (domain context, a bounded language, governed autonomy, observable feedback loops, self-service golden paths) are precisely the principles AI agents need at scale. An agent building a healthcare service without the relevant privacy rules, or a payments service without card-security defaults, will produce systems that are technically functional and non-compliant, at scale. It’s a good argument that the automated checks around coding agents need domain defaults, not just tests and metrics (Don’t Read the Code? Verifying AI-Written Code).

Systems improve in a crisis

Large ransomware outbreaks spread through systems that administrators then had to patch by hand. Security and compliance had long been treated as a tax, until a widely known incident showed what platforms that owned those measures could have prevented. Usually, systems only improve in a crisis.

Through a training lens

Two metaphors helped me here:

• Form before load. Flaring the elbows or letting the shoulder blades go slack in a push-up feels easier at the time. But friction, tendon trouble and inefficiency build up, and progress stalls. A platform out of line with its domain does the same thing. Fixing form is what builds progress.
• Deload before the injury. Improving systems only after a crisis is like deloading only after an injury, then adding warm-ups and changing the plan. It’s far cheaper to plan the deloads in (Deloads Are Tech-Debt Sprints).

Related: Internal Developer Platform · Explore, Expand, Extract · Deloads and Tendon Adaptation