Domain-driven platform engineering is the future | Weave Intelligence

Platform engineering is evolving beyond infrastructure automation into a discipline that must speak the language of business domains. As enterprises expand platform responsibilities to serve AI workflows, data teams, and diverse developer personas, the traditional "one platform for everyone" approach is breaking down.

Main insights

• Platform engineering without domain context becomes "infrastructure with pretty UIs and pretty APIs" - it must translate developer intent into domain-specific capabilities

• The three pillars of domain-driven platform engineering are domain-aligned boundaries, ubiquitous language in platform APIs, and bounded contexts with anti-corruption layers

• Platform teams now serve an exploding range of users - from traditional developers to citizen developers to AI agents - requiring new levels of abstraction and specialization

• AI workflow responsibility among platform teams jumped from ~5% to ~40% year-over-year, signaling rapid expansion of platform scope

Ajay Chankramath brings over three decades of technology leadership to this conversation. As CEO of Platformetrics and co-author of "Effective Platform Engineering", he has been at the forefront of platform engineering practices. His experience includes leading platform engineering at ThoughtWorks and serving as CTO at Brillio.

You can watch the full discussion here if you missed it.

What is domain-driven design and why does it matter for platforms

Domain-driven design (DDD) is fundamentally about architecting software systems with principles that match specific business domains - whether banking, healthcare, manufacturing, or any industry vertical. The approach ensures your architecture supports the products and outcomes needed for that particular domain.

For platform engineering, this creates an important shift in thinking. As Ajay explains, "Platform engineering without domain context is infrastructure with maybe pretty UIs and pretty APIs. That's great, but most platform teams are not built for average developers." The reality is that an ML engineer needs GPU orchestration, a fintech team faces compliance challenges, and a front-end developer just wants to ship code quickly. Each has different domain-specific needs.

The key insight: platform domains are what you build with; business domains are who you build it for. Platform domains include things like cloud administration, identity management, and control planes - the infrastructure building blocks. Business domains are industry or capability contexts like payments processing, healthcare claims, retail fulfillment, or insurance underwriting.

Ajay uses a memorable kitchen analogy: "Platform domains are like ingredients in a kitchen - you have your flour, your eggs, and butter. Business domains are like cuisines - Italian, Japanese, Mexican. Same ingredients but combined and presented completely differently based on the context." You wouldn't hand flour, eggs, and butter to a five-year-old and expect them to create something useful. Similarly, handing developers raw Kubernetes abstractions without domain context misses the opportunity to serve them better.

The three pillars of domain-driven platform engineering

Domain-driven platform engineering rests on three foundational pillars that translate DDD principles into platform practice:

1. Domain-aligned boundaries
Platform capabilities must map to business domains, with each domain getting its own language or dialect of the platform. A compliance domain gets audit trails baked in by default. A data science domain gets experiment tracking built into its workflows. The purpose is the same - observability, deployment, integration - but the specific dialect changes based on domain needs.

2. Ubiquitous language in platform APIs
Instead of infrastructure jargon, platform APIs should speak the domain's language. This isn't about dumbing down for developers who don't know Kubernetes - most do. It's about raising the abstraction level to what's relevant for the payments platform developer specifically.

3. Bounded contexts with anti-corruption layers
Platform services like deployment have clear boundaries matching domain boundaries. Anti-corruption layers protect domains from platform changes, allowing teams to evolve independently without breaking contracts. A payments team and a risk compliance team can both evolve their use of the platform without interfering with each other.

These pillars align directly with established platform engineering practices. Team topologies tells us how teams should interact; domain-driven platform engineering tells us how each team's platform interface should look. Platform-as-a-product thinking says treat your platform as a product; domain-driven platform engineering says your platform has multiple products for multiple customer segments.

Practical adoption: From theory to implementation

Moving from traditional platform engineering to a domain-driven approach follows a pragmatic path:

1. Map your domains - Identify three to five core business domains. Understand their unique requirements versus generic requirements. Look for special cases breaking your generic systems - these signal where domain-specific abstractions add value.

2. Pilot one domain - Pick a domain with clear boundaries and a team ready to collaborate. Build the capabilities needed for that specific domain.

3. Extract patterns - Document what worked and what didn't. Identify which patterns apply to other domains and which remain domain-specific.

4. Scale thoughtfully - Apply learned patterns to additional domains while respecting their unique contexts.

This approach mirrors how software engineering has always evolved - start with a foundation, build on it, and keep shifting the abstraction level. The difference now is intentionally designing those abstractions around business domains rather than purely technical concerns.

The expanding scope of platform engineering

Recent data from the State of Platform Engineering report reveals a dramatic shift: platform teams responsible for AI workflows jumped from approximately 5% to 40% year-over-year. This explosion in scope extends beyond AI to include data platforms, security platforms, observability platforms, and more.

The number and type of users is also exploding. Platform teams historically served application developers. Now they serve data scientists, ML engineers, security teams, and increasingly, citizen developers - anyone who can describe what they want in natural language. Soon, AI agents will join as platform consumers.

As Ajay notes, "Every platform team thinks they are building for developers, but developer isn't a persona or job title anymore. It's highly democratized. Your product manager would be that developer." This democratization means understanding your domain becomes the single biggest requirement for building successful platforms and delivering real business value.

AI, agents, and the future of platform work

The rise of AI coding assistants and agentic workflows is reshaping what platform engineering means. Ajay observes that while citizen developers can now build apps through natural language, "the difference is how do you actually make it production-ready and scalable and something beyond just a web-facing app." Enterprise-grade platforms require more than code generation. They need:

• Deterministic infrastructure and configuration - Non-deterministic AI systems need deterministic architectural foundations

• Domain-specific guardrails - Preventing agents from making changes that violate domain constraints

• Quality assurance layers - As code generation approaches zero cost, QA and integration become where backend value lies

• Integration capabilities - Programmatic access to capabilities becomes more sophisticated and valuable

The role of platform engineers is evolving from pure builders to supervisors and quality controllers. Product managers gain elevated importance as those who best understand intent. But the core architectural principles - the ones domain-driven platform engineering helps establish - remain essential to prevent non-deterministic systems from creating chaos in production.

Ajay warns: "Right now, as things stand, this is just waiting for that next big disaster because we don't have the guardrails around some of these things." The solution isn't to avoid AI and agents, but to build platforms with strong domain-driven foundations that can safely leverage these capabilities.

Key takeaways

• Shift from generic to domain-specific platforms - Stop building one platform for everyone. Instead, translate platform capabilities into domain-specific languages and workflows that match how different teams actually work. This reduces friction and increases adoption.

• Apply the three pillars systematically - Implement domain-aligned boundaries, use ubiquitous language in your APIs, and create bounded contexts with anti-corruption layers. These aren't just theoretical concepts - they're practical design principles that prevent platform changes from breaking domain teams.

• Start small and extract patterns - Don't try to solve all domains at once. Pilot with one domain that has clear boundaries and a willing team, learn what works, then scale those patterns to other domains while respecting their unique contexts.

• Prepare for AI-augmented platform work - As AI agents and citizen developers become platform consumers, domain-driven foundations become more critical, not less. Strong architectural principles and guardrails are what separate production-ready platforms from experimental prototypes.