Service

A service is a boundary-relative role in which a provider makes a capability available to a consumer through a contract. The role says what can be requested, observed, or relied upon at that boundary; it does not by itself determine where the behavior is implemented, whether it runs in another process, how it is deployed, or which team owns it.

The unqualified word service is therefore incomplete in a system model. The capability, provider observer, interaction contract, semantic authority, code, deployment, runtime process, and organizational owner may have different identities and lifecycles.

Qualified Meanings

Term	Center of gravity	Cohesive correspondence	Does not imply
Domain service	domain semantics and DDD	A domain operation, policy, transition, or process expressed in the domain language when responsibility does not naturally belong to one entity or value. Its interface and decisions belong to the domain model.	An application coordinator, network endpoint, daemon, or independently deployed service.
Application service or Service Layer	system graph and architecture practice	An application-boundary observer role that admits commands or queries, coordinates domain work, transactions, and effects, and returns observations.	New domain meaning merely because it coordinates domain behavior.
Background service or daemon	realization substrate	A runtime-managed process, worker, or application host activated by boot, timers, queues, files, messages, or other triggers and governed by lifecycle and scheduling mechanisms.	A domain service, application boundary, or microservice.
Microservice	architecture practice spanning several realms	An independently evolvable service boundary whose semantic responsibilities, interactions, guarantees, code, ownership, deployment, and runtime realization are deliberately aligned.	A fixed code size, one module, one repository, one process, one team, or one bounded context.
Queueing service	analytical and operational language	Processing supplied by a service center, described by service time, service rate, capacity, and queue discipline.	Any of the software-architecture meanings above.

Relationships among the Meanings

One microservice may expose several application services, run several background workers, and use domain services inside its model. The same domain service can be realized inside a modular monolith, microservice, command handler, workflow activity, or background worker. An application service can be invoked locally or exposed through a remote endpoint. A daemon may host a microservice or perform supporting infrastructure work, but running out of process does not make it a microservice.

Encapsulation and Bundling

The common role across these meanings is encapsulation. A service bundles some internal structure and presents a more stable, selective interaction surface to consumers:

service = encapsulated internal subgraph
        + provided interfaces
        + required interfaces
        + declared guarantees
        + accountable ownership

The internal subgraph may contain entities, policies, domain services, queries, processes, code modules, storage, workers, or calls to other services. Its interfaces expose capabilities without requiring consumers to know that internal arrangement. This is boundary-relative: a composite service may encapsulate several downstream services for one consumer while appearing as a dependency node to another.

Encapsulation can be semantic, structural, operational, organizational, or some combination. A model should say which internal changes consumers are protected from and which guarantees remain valid across the interface.

Facades, Gateways, and Services

The GoF Facade pattern has a close structural correspondence: it provides a unified, simplified interface to a subsystem. A service can act as a facade, but service is the broader role. A service interface may carry semantic authority, remote failure, compatibility, security, throughput, and operational commitments that an object-oriented facade does not imply.

Role	Primary purpose
Facade	Simplifies access to an internal subsystem without implying a deployment or network boundary
Adapter	Translates one interface or representation into another
Gateway	Controls or translates passage across an external, trust, protocol, or topology boundary
Aggregator	Combines correlated results or values under an explicit completion rule
Service	Provides a capability while encapsulating how it is realized

A single node can fulfill several of these roles, but naming each role separately exposes its obligations.

Capability and Composition Roles

Industry terminology varies, so a service should be classified on two independent axes: whether it owns semantic authority and whether it primarily realizes behavior locally or composes dependencies.

Semantic role	Realization role	Recommended description
Owns a domain capability	Primarily local	Capability-owning service
Owns a domain capability	Substantially composes dependencies	Capability-owning composition service
Does not own domain semantics	Provides reusable technical behavior	Technical or utility service
Does not own domain semantics	Routes, translates, aggregates, or coordinates dependencies	Composition service, qualified as gateway, aggregator, facade, or orchestrator

Composition is not synonymous with semantic emptiness. A composition service owns domain semantics when it decides domain-valid sequencing, eligibility, policy, or outcomes; it is composition-only when it preserves the authority and meanings of downstream capabilities while changing their accessibility or presentation.

The same distinction applies at the operation level:

Operation role	Meaning
Authoritative command	Decides or records a semantic transition under local authority
Local query	Reads locally governed state or a declared projection
Delegating operation	Preserves another capability's meaning while invoking its provider
Routing operation	Selects a destination without combining semantic results
Aggregate query	Combines several observations under an explicit completeness rule
Composite command	Coordinates several commands and owns the exposed outcome contract
Process operation	Starts, advances, signals, or observes a semantic process
Translating operation	Adapts shape, protocol, or vocabulary across boundaries

Service models use these roles to distinguish a service's visible node from the entities, relations, queries, processes, and dependencies it encapsulates.

The direction of realization is therefore:

domain capability or operation
  -> application-boundary coordination
  -> code modules and interaction contracts
  -> deployment units and runtime processes
  -> scheduler-managed executions

This is a possible correspondence, not an identity chain. A layer may be absent, combined with another layer, or realized in several ways.

Modeling Discipline

When using service, state:

Which capability is provided, to whom, and at which boundary?
Which observer interprets the request, message, timer, or other input?
Where do domain rules, transition authority, coordination, and effects belong?
Which provided and required interfaces declare the available interactions and semantic contracts?
Which interaction protocols govern ordering, concurrency, completion, cancellation, and failure?
Which channels and network bindings realize those interfaces?
Which operational guarantees apply to delivery, ordering, consistency, recovery, and compatibility?
Which code modules, repositories, build artifacts, deployment units, runtime instances, and schedulers realize the role?
Which team owns semantic change, contract evolution, deployment, and operation?

Names such as CustomerService, a /services directory, a service-manager unit, or a network endpoint are realization evidence, not proof of any particular service meaning.

External References

Eric Evans, Domain-Driven Design Reference, especially the Service pattern.
Randy Stafford, Service Layer, Patterns of Enterprise Application Architecture.
Erich Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software, Facade, 1994.
Refactoring.Guru, Facade.
Linux man-pages project, daemon(7).
James Lewis and Martin Fowler, Microservices, 2014.