A Service is a Logical Construct Built by Microservices

| by Jan Stenberg Follow 34 Followers on Mar 31, 2015. Estimated reading time: 2 minutes |

A service is a logical construct owning a business capability and made up of internal autonomous components or microservices that together fulfil all responsibilities of the service, Jeppe Cramon suggests discussing SOA and Microservices in the light of autonomous services, a follow up on a previous series of blog posts clarifying his view on building services around business capabilities and bounded contexts.

Cramon, a Danish contractor working with large-scale system integration, earlier suggested that services should be built around business capabilities but now rephrases that to suggesting that services should be aligned with business capabilities and refers to Udi Dahan who claims that a service should be the technical authority for a specific business capability with any piece of data or rule owned by only one service.

Cramon summarizes his view into four rules, defining that a service:

  • Is the technical authority for a given business capability.
  • Is the owner of all the data and business rules that support this business capability wherever it is needed.
  • Forms a single source of truth for that capability.
  • Ensures we can maintain autonomy and encapsulation.

The consequence of these definitions is that a service needs to be deployed and available everywhere its data/logic is needed and for Cramon this implies that a service is a logical construct and refers to Philippe Krutchen and his 4+1 architectural view model that separates the logical view of a system from the physical view. To be able to build applications around these logical services it must be possible to deploy many services into the same system or application and on the same server.

With a service being a logical construct Cramon suggests it should be built up using autonomous components or microservices that together fulfil the functional responsibility of the service, effectively making microservices an implementation detail of a logical service. Each microservice within a service has its own domain model, publish events emerging from this domain for other microservices to consume and expose one or more endpoints for external actors to interact with, using e.g. HTTP. An endpoint can also be a normal in-process interface which can be used without requiring a remote call.

Cramon finishes by stating there are no reasons a microservice must be deployed in its own process. They are logically deployable units that may be deployed individually, but this should be considered only when it makes sense.

Both Dahan and Cramon held a presentation at the Microservices Conference November last year.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread


Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you