Ubiquitous Language for Platforms

The simplest principle in domain-driven design is that everyone working in a bounded context speaks the same language, and that language comes from the people who use the system. Applied to platforms, it means more than consistent naming: the platform should feel native to each domain it serves.

The translation tax

Platform engineers think in infrastructure: pods, sidecars, service meshes. The developers consuming the platform think in their domain: payments, orders, recommendations. Every time someone has to translate “deploy my payment service” into “configure a Kubernetes deployment with sidecar injection”, their cognitive load goes up and the platform’s adoption goes down.

That translation is a big part of The Platform Relevance Gap: the platform has the capability, but not in the shape the team needs.

Closing it

• Name things after what teams build, not how they’re run: “new payment service”, not “new Helm release”.
• Domain-shaped golden paths (Golden Paths) whose defaults already know the domain’s needs, such as compliance rules for payments or health data.
• Hide the plumbing, keep the context. The goal is fewer translations, not fewer details: teams still need to see what’s running when something breaks.

A good test, borrowed from the book’s readiness assessment: does your platform speak domain language?

It’s the same move as modelling API responses in your own types, so the UI speaks the product’s language rather than the backend’s (API Modelling).

From chapter 3 of Domain-Driven Platform Engineering.