Service layer pattern

Grouping services into functional layers reduces the impact of change. Most changes affect only the layer in which they're made, with few side-effects that impact other layers. This fundamentally simplifies service maintenance.

The service reusability principle dictates that services should be designed to maximize reuse. Similarly, the service composability principle advocates designing services so that they can be composed in various ways. Both principles require that a service contain only a specific type of logic e.g., either reusable or process-specific logic. Restricting each layer to a particular functionality, simplifies the design of the service.

Applying this pattern requires creating a service inventory blueprint, a list of services with associated functionality. Next, group the services into layers according to function. Adopting a common layering strategy across the enterprise facilitates reuse in other applications, because developers don't have as much to learn (or invent) when they join a project. One common layering uses task, entity and utility.

An alternative layering from Bieberstein et al., involves five layers, namely enterprise, process, service, component and object.

The service layer pattern invokes a specific service architecture.

The top-down service delivery approach facilitates the use of this pattern.