Service

Origin & evolution

The word carried a looser meaning for years before the discipline tightened it. Service-Oriented Architecture in the early 2000s framed a service as a reusable, network-accessible business capability💪CapabilityStrategyAn ability that enables value deliveryView reference →, often mediated by heavyweight middleware and an enterprise service bus. The promise was reuse; the common outcome🏆OutcomeStrategyA desired business or user outcomeView reference → was a brittle, centrally governed monolith wearing a distributed costume.

The corrective came from the bounded-context idea in Eric Evans' Domain-Driven Design (2003), which argued that a model is only coherent inside a clear boundary. James Lewis and Martin Fowler drew the two threads together in Microservices (2014), defining a service as a small unit built around a business capability, independently deployable, owning its own data, and communicating over the network. The boundary became the point. A service you cannot deploy without coordinating three other teams is not really a service.

The pendulum has since swung back toward judgement. Practitioners now talk about right-sizing, the modular monolith, and the cost of premature decomposition, because every network boundary you draw is a distributed-systems problem you have agreed to own forever.

How it works in practice

An e-commerce platform splits its monolith and carves out an inventory service. It owns one database schema🗄️Database SchemaEngineeringA database schema definitionView reference →, exposes a handful of API endpoints🔌API EndpointEngineeringA specific API endpointView reference →, publishes a stock.reserved event to a queue, and is deployed twelve times a day by the four engineers who own it. Its blast radius is its own: when inventory falls over at 2am, checkout degrades to "ships in 3 to 5 days" instead of failing, because the boundary was drawn to fail gracefully.

The team commits to a service level objective🥅Service Level ObjectiveDevOps & PlatformA service level objective (SLO)View reference → on the read path and tracks the deployments📤DeploymentEngineeringA deployment eventView reference → that move its error rate. When a regression appears, they know which service to roll back without asking anyone, because the service owns its code, its data, and its on-call rotation as one unit.

Service vs. its neighbours

• API endpoint is a single door the service exposes; the service is the whole building behind it. The service holds the state, the dependencies⛓️DependencyTeam & OrganisationA cross-team or system dependencyView reference →, and the deployment; the endpoint is one operation it serves.
• Bounded context🔲Bounded ContextEngineeringA DDD bounded context defining a service boundaryView reference → is the conceptual boundary, a region of the domain model where terms mean one consistent thing. A service is the runtime realisation of a bounded context, though the mapping is not always one to one. One context can be served by several collaborating services.
• Deployment is a specific act of putting a version of the service into an environment. The service is the long-lived thing; a deployment is one event in its history. You roll back a deployment, you do not roll back the service.

In the graph

In the Unified Product Graph, service⚙️ServiceEngineeringA deployable service or microservice is the anchor of the Engineering and Platform region, chosen because it has more hierarchy children than any other entity in the spec. Its intra-region edges fan out to the things it owns: service_serves_api_endpointServiceservesAPI Endpointhierarchy, service_exposes_api_contractServiceexposesAPI Contracthierarchy, service_persisted_in_database_schemaServicepersisted inDatabase Schemahierarchy, service_publishes_to_queue_topicServicepublishes toQueue Topichierarchy, service_deployed_as_deploymentServicedeployed asDeploymenthierarchy, service_toggles_feature_flagServicetogglesFeature Flaghierarchy. The boundary edge service_powers_featureServicepowersFeaturecross-domain crosses into Product and Delivery, and service_level_agreement_governs_serviceService Level AgreementgovernsServicecross-domain reaches in from Operations and Quality. That shape makes the service a hub: trace outward and you see what it runs, trace the imports and you see what depends on it and what it owes.