Service API Patterns, Metrics > Service API Management Patterns > Service Decomposition
How can the granularity of a service be increased subsequent to its implementation?
Services may be initially designed with a coarse level of service granularity or they may become more coarse-grained over time, as functions are added in response to new requirements. However, at some point, it may become evident that the functional scope of a service has become bloated to an extent that the service is no longer performing adequately at runtime. Or, perhaps the service has become burdensome to maintain, scale or administer due to it having to serve too many different types of service consumers.
The Service Decomposition pattern is applied to decompose a coarse-grained service into a set of fine-grained services that collectively represent the functional scope and context of the original service, but establish distinct functional contexts of their own.
The coarse-grained Invoice service is decomposed into a set of fine-grained services that collectively provide the functionality of the original Invoice service.
Carrying out this pattern essentially requires that the existing, coarse-grained service be broken apart and its logic reorganized and optimized into new, finer-grained functional boundaries.
The three new fine-grained services are implemented with correspondingly narrower service APIs and individually leaner service architectures.
Unless it is decided to also retrofit previous service consumer programs that formed dependencies on the original service API, the Proxy Capability pattern will likely need to be applied to preserve the original service API for backwards compatibility purposes.
The preventative application of the Decomposed Capability pattern can ease the impact of applying the Service Decomposition pattern and will also result in a cleaner separation of functional service contexts.