Now that we have a solid understanding of applying Team Topologies (TT) concepts to platform engineering and how this concept applies to stream-aligned teams within an organization, many of us have been considering the innovative potential of using these concepts across a wide range of domains. Suppose you are unfamiliar with the basic foundational concepts of Team Topologies. In that case, we recommend you check out the key concepts section of the Team Topologies site to familiarize yourself with it. The 9/6 model of Team Topologies remains as expansive and accurate as ever, regardless of the type of organization I have encountered.

In this blog, I will share my experience combining principles of Team Topologies and domain-driven platform engineering to create a more scalable, adaptive, and developer-centric platform organization by enabling clear team boundaries. This will create a more optimized cognitive load and dynamic evolution aligned with business domains. The term domain-driven platform engineering (DDPE) is likely new to the reader. Please check out some basic ideas and the need for DDPE in this article.

Why Structure Matters in Platform Engineering?

The rise of internal developer platforms with solid orchestrators (Humanitec, Mia-Platform, Kratix) has shifted the narrative from traditional infrastructure-centric approaches to productized services. Developers, having experienced the success of reduced cognitive load and the ability to be autonomous in building and delivering their products for Non-Functional Requirements (NFRs), are increasingly looking to map these learnings to the domain-centric aspects of their development. The past year has been increasingly "distracting" for an average developer, with the idea of agentic self-evolution attempting to trump the self-service. This has only exacerbated the problems for them as the decision-makers in the organizations are asking why the promised acceleration hasn't reached them fast enough.

In addition, most organizations fail to scale platform efforts due to ambiguous team boundaries, overburdened platform teams, and a disjointed developer experience. One of the FAANG companies I've interacted with still employs a federated platform engineering approach, where a specific domain team's ability to push the boundaries of its capabilities is severely curtailed by the need to collaborate with the mother ship. While adopting a platform model, a major Canadian insurance company found significant benefits for its greenfield operations but fell short in its brownfield initiatives. These challenges are often attributed to the 'I-told-you-so' crowd, who continue to claim that platform engineering is just the next fad that will die down. I attribute this to their lack of familiarity with the concepts of Team Topologies and the Platform-as-a-Product mindset, which form the backbone of this movement. In this context, aligning platform engineering structures with TT and DDD principles provides a sustainable and business-aligned approach to building and evolving platforms.

Before we proceed, a high-level view of how domain-driven platform engineering looks is prudent.

Figure 1: High-Level View of the Abstraction and Domain Dichotomy

Applying the DDPE Lens to the Four Fundamental Team Types in Platform Context

This section will examine the four fundamental topologies and how overlaying a domain-centric approach would enhance our discussion.

Stream-Aligned Teams

These teams are most closely aligned to a business domain or value stream. However, by definition, a domain spans multiple stream-aligned teams and a lesser number of complicated teams. These teams consume platform capabilities via self-service APIs, golden paths, and paved roads. Applying the DDPE lens, you will find that a stream-aligned team maps to a business subdomain and interacts with the platform via domain-specific capabilities.

Platform Teams

These teams provide reusable services and paved paths to streamline delivery for stream-aligned teams. They typically own the platform building blocks, such as CI/CD pipelines, observability, Identity and Access Management (IaM), Compliance, and often Infrastructure as Code (IaC) and Runtime platform capabilities. In the DDPE world, you need additional capabilities to be segmented and offered per domain context, not just monoliths. An approach like that leads to the extension of the TT model. You might ask why the platform teams or complicated subsystems would not provide these and why you need a separate construct to achieve this. The answer is pretty simple. In my experience, the skill sets required for the domain abstraction we discuss here do not lend themselves well to the above team constructs.

Enabling Teams

These teams within your organization help stream-aligned teams adopt new platform capabilities or improve their practices (some might know them as your neighborhood Centers of Excellence (COEs)). While they might often be short-lived and could take an advisory role, it does not necessarily have to be so. The enabling teams have a significantly interesting role when applying the DDPE lens. Instead of being the bridge between generic platform tooling and stream-aligned teams, their role expands to address domain-specific adoption pain points.

Complicated subsystem teams

While these teams handle areas requiring deep specialist knowledge that may be difficult to hire and retain in large quantities, in the DDPE world, they can build specialized subsystems used across multiple domains and platforms. My interpretation of the Complicated subsystem teams has always been that the capabilities these teams provide are specialized.

Cognitive Load as a Design Principle

As you can see in our example, the domain expertise required for implementing the abstracted-out capabilities neither falls within the platform team nor the complex subsystem teams. Today, it falls under custom development within the stream-aligned teams, which is gradually integrated into third-party platforms through platform APIs that connect with external products built by the SA teams. However, the accepted premise is that overloaded teams are typically a symptom of poorly defined platform responsibilities, abstractions, or both. So, if the cognitive load is a constraint, it becomes a design principle. Interpreting it as a design principle can lead to two simple decision points:

Don't make platforms too generic.
Design each capability around the domain needs and the maturity of the teams.

Applying this in the context of DDPE, you will find that a platform team supporting retail checkout and fraud detection requires different support models, as the skills required and domain complexities differ. Now, why should this be abstracted out? We need it abstracted because checkout or fraud detection shouldn't be duplicated for a product organization. For a services organization, where they can claim they don't care at some level, building accelerators around these platform capabilities is usually the difference between success through repeatability and the failure of creating umpteen different implementations of checkout features. But we don't do it. A standard platform, such as Shopify, typically provides a customizable checkout experience for online stores. It uses APIs to enable the product teams to personalize and integrate the process with their services. However, the cognitive load lies in the breadth of various platforms, such as Shopify, that one would use within the ecosystem.

Applying DDPE to the 9 Core Principles and 6 Team Patterns

As we apply the DDPE to the nine core principles of Team Topologies and the six team patterns, let's explore the overall shift in abstractions you need

Figure 2: Movement from highly abstract, generic platform services to domain-specific, business-aligned services

Nine Principles

Focus on Flow, Not Structure It is recommended that organization should be around domain value streams (Retail, BFSI, HCLS) to reduce silos between platform layers and domain-aligned services. This way, optimizing flow from idea to running service in a specific domain becomes more of a reality.
High Trust Is Non-Negotiable: You must trust domain-aligned teams to choose tools and platform capabilities that fit their needs. Often, the challenge comes from over-governance in platform use. We used the example of Shopify above, but we provided the teams with the ideal.
Keep Teams Together: One challenge I have observed is that, in the organization’s desire to increase efficiency, the constant rotation of resources creates inherent instability. Stabilizing domain platform teams (e.g., the HCLS platform team) instead of constantly rotating engineers across backend, infrastructure, and DevEx creates more confusion than losing valuable historical knowledge to build capabilities more effectively.
Respect Cognitive Limits: Respect cognitive limits by modularizing domain capabilities as much as possible. Use DevEx metrics to measure effectiveness and make strong decisions to resist the urge to throw more domain capabilities to the stream-aligned team. Look for where the abstraction can be shifted and create additional domain-platform teams. Letting a single team own a whole domain is asking for trouble. Identify the ideal boundaries through effectiveness metrics and customer-visible issues to create more cohesive and self-contained teams.
Make Changes Small and Safe: Designing DDPE platforms with thin slices and versioned service interfaces will enable a safe rollout of new domain features and platform capabilities, where design and Razer-focused interface testing minimize the number of changes.
Connect Teams Directly to Customers: Stream-aligned domain teams (Retail, BFSI) must regularly engage business and end-users to shape platform accelerators and domain logic. There is nothing new here, but if the scope of these domain teams exceeds what you would want, customer interaction becomes a chore and does not achieve what you intended in the first place.
Embrace Complexity, Don’t Fight It: Build layered platform ecosystems, as shown in Figure 2, that absorb complexity in integration, compliance, and orchestration layers, rather than pretending to a one-size-fits-all approach. If you need to add more platform ecosystems, do so without fear that it might be challenging.
Foster Continuous Discovery: Enable discovery pipelines in domains (e.g., A/B experimentation in Retail, analytics sandboxes in HCLS) backed by platform self-service and DevEx tooling. Continuous delivery can happen for each sub-component (Boxes inside the boxes) of Figure 2. This is a surefire way to achieve faster convergence and integration, rather than creating a larger, monolithic buildout of your microservices.
Eliminate Team Dependencies: This can be the most challenging part of DDPE, but it does not have to be. Give stream-aligned domain teams autonomy over their tech stacks via a stable API/contract from DevEx and Core Services. Avoid blocking central approvals. Yet again, your contract testing becomes critical in this context.

Six Patterns

Let us examine whether any of the well-understood six patterns require fundamental rethinking as we introduce increased domain centricity.

4 Team Types: It is a matter of interpretation, but keep the four types the same as the original. However, there should be a clear understanding of where the domain backbone and standard enterprise services (refer to Figure 2) would be placed. Lack of clarity can be a significant problem for either the foundational services teams or the unique domain services, which would be affected by it. I recommend a pattern along the following lines to address this.

Stream-aligned teams are now anchored in specific domain value streams, supported by platform teams delivering foundational services via an X-as-a-Service model. A dedicated Enabling Team spans multiple domains, facilitating capability uplift across stream-aligned teams, especially when collaborating with Complicated Subsystem Teams to build complex domain logic. The model integrates continuous feedback loops between stream-aligned and platform teams, and promotes domain-backbone services as a bridge between foundational capabilities and specialized domain logic. Interaction modes—collaboration, facilitation, and service consumption—are explicitly mapped to streamline flow and reduce friction between team layers, ensuring platform and domain services evolve in lockstep with business needs, even with the introduction of the domain backbone and standard enterprise services.

Figure 3: Mapping Domain-Backbone services and Common-Enterprise services to the 4 Team Types

Collaboration modes will be relatively simple, as the X-as-a-Service mode will be reused for interactions between Domain-Backbone services and stream-aligned teams, and Common-enterprise services and the platform team. No appreciable adaptation is needed for managing the cognitive load, TVP, Flexible Team boundaries, and continuous adaptation, highlighting the power of the TeamTopologies model. Key principles to consider here are:

Do not overload domain teams with domain-backbone services
Do not overload platform teams with common-enterprise services
Start with the master TVP architecture and use the contract testing to ensure that the responsibilities remain autonomous
It is perfectly fine for the platform teams to shift responsibilities between Common-Enterprise services and stream-aligned teams, depending on the level of maturity achieved, with domain-backbone services.
Periodically review the feedback loops to evolve this structure.

Conclusion

In conclusion, the hypotheses we tested here, whether we can effectively apply them to organizations moving towards domain-driven platform engineering, are proven right. The following is a summary of the key points that emerged from the discussion.

Subscribe to the Team Topologies newsletter

Designing Platform-Centric Organizations with Domain Thinking and Team Topologies