Of course, most services are not built as new services, they are exposed out of existing systems. So, how you expose services in that manner is a bit more involved, especially when considering granularity. In essence you’re not designing a service, but you are designing the abstractions of that service.

When exposing existing services you typically can’t decide as to what will exist as a raw service in the systems your exposing, however you can abstract them in such a way that you create a set of well designed and defined services, even if the raw (originating) services are not.

For instance, we may look to expose a very course grained service, an poorly designed API perhaps, found in an existing legacy application.. Say the pattern is: Manage Employees, which is a complete set of functions bound to a single API call or service that manages all employee data, including add, edit, validate, update, delete, etc.

We are able to expose this API as a service, but we may want to go a few steps further including breaking this service out into many independent services by building abstract services (plural) above the raw service. It’s the role of this process to make the larger more course grain service appear as fine grained or as course grained as needed for a good usable design.