Domain-Driven Platform Engineering
Ajay Chankramath and Eamonn Ryan · 2026
How to build context-aware, scalable, self-service platforms for the enterprise, using domain-driven design to decide what the platform should own.
📖 Still reading this one, so these notes will grow.
What it’s about
A 2026 book on applying domain-driven design to platform engineering in large organisations: how to work out what a platform should own, how to keep it aware of the context of the teams using it, and how to make self-service work at enterprise scale. I’ve only just started it, so this note is early impressions rather than a summary.
What I’m learning so far
Boundaries come from the domain. It’s tempting to carve a platform up by tool (a CI team, a Kubernetes team, a portal team) or by org chart. The book’s starting point is that platform boundaries should follow the domains teams actually work in, the same way service boundaries should.
Self-service needs context. A self-service platform that ignores what a team is building (its data, its compliance needs, its traffic) pushes the hard decisions back onto the team. Context-aware platforms make sensible defaults possible.
It picks up where Hohpe left me. Platform Strategy gave me the idea that platforms belong in supporting domains. The open question was how you actually draw and govern those boundaries when there are hundreds of teams. That’s what I’m reading this for.
What I’m watching for
There’s nothing applied to report yet, so this is what I want to get out of it:
- A practical way to map supporting domains in an existing organisation, rather than a greenfield one.
- How the book handles ownership when a capability serves several domains at once.
- Whether it treats AI agents as platform consumers, which is where my own thinking is heading (Thinking in Platforms).
Where I’d use it: the next time I’m involved in platform discovery, to sequence capabilities by domain need rather than by which tool is easiest to roll out, much like the dependency map in Skill Trees as Platform Capability Maps.
Where it connects
Where Platforms Fit: DDD Subdomains · Internal Developer Platform · Golden Paths · Skill Trees as Platform Capability Maps · Platform Strategy
↩ Mentioned in (3)
Twenty-odd books across code, platforms, teams, trading and science fiction turn out to make the same five arguments. Here's the thread that connects them.
book · Gregor Hohpe
Platform StrategyWhat makes a platform genuinely useful to the teams on it, rather than just shared infrastructure.
book · Kaspar von Grünberg and Luca Galante
Thinking in PlatformsPlatform engineering as the operating model for knowledge work in the AI era, with agents as platform users.