Domain team

As explained in Effective Platform Engineering

A development team is a group responsible for building and operating one or more software applications or services.

A domain team is an autonomous development team responsible for delivering and operating capabilities within a defined product domain. In platform engineering, domain teams divide a growing platform into smaller parts while following shared engineering principles and responding to user feedback. section 1.3 section 9.0

A domain team typically owns responsibilities close to the applications or services it supports:

• Configure service-specific dashboards, define meaningful alerts, and publish traces for operational monitoring. section 5.2.3
• Use platform-provided tools and frameworks while retaining responsibility for insights into the team’s own services. section 5.2.3
• Scale independently within clear domain boundaries, using shared principles and self-service interactions with other platform teams. section 1.3 section 9.0

The pattern separates responsibilities without creating isolated teams. A platform team maintains shared mechanisms such as metrics scraping, trace ingestion, storage, and hosted observability tools; domain teams apply those capabilities to their services. As adoption grows, event-driven releases and contract tests help preserve reliability and trust across team boundaries. section 5.2.3 section 9.0

Observability ownership

An application team monitors its own service by creating dashboards, setting response-time or error-rate thresholds, and publishing traces. The platform team provides the collection, ingestion, storage, and hosting infrastructure needed to make those signals usable. section 5.2.3

Figure 1.3 Platform engineering depends on the disciplined application of a product delivery model. Product management drives decisions about the product’s capabilities, features, and experiences. Effective platform engineering principles enable us to deliver these more successfully. Identifying and architecting around the internal product domains of our platform is how we successfully sustain the user experience as the product evolves and scales.

Use the platform product-delivery model to relate product management, platform capabilities, internal domains, and the user experience as the platform evolves. section 1.3

How Effective Platform Engineering covers it

How deep it goes

Explains team boundaries, shared responsibilities, observability duties, autonomy, and scaling practices across platform domains.

Examples

Uses dashboards, alerts, traces, metrics scraping, trace ingestion, hosted observability tools, event-driven releases, and contract tests.

What you can do after

Operate services through explicit ownership of monitoring configuration while consuming shared platform infrastructure.

How it connects

Connects domain-driven design, platform engineering, product delivery, observability, shared responsibility, and contract testing.

liveBookmanning.com

Read Effective Platform Engineering on liveBook Get the book at manning.com

Related concepts

• productpart of · A product is a good, service, software offering, or other managed offering made available to customers or users to provide value.
• domain-driven designproduced by · Domain-driven design is a software design approach that centers models, structure, and terminology on the concepts, behavior, and boundaries of a problem domain.
• dashboarduses · A dashboard is a visual interface that consolidates selected data, metrics, or status information for monitoring, analysis, or decision-making.
• roadmapuses · A roadmap is a time-oriented planning artifact that communicates intended goals, initiatives, milestones, capabilities, or changes and their sequence.
• teamincludes · A team is a group of people who collaborate and share responsibility for achieving a common objective.

This explainer was generated by Manning's knowledge graph from the text of Effective Platform Engineering. The section links point to the parts of the book it draws on.