- Proxy Capability – When logic is moved from one service to another, this pattern can be used to preserve the original capability that is expressed as part of the original service’s contract.
- Service Façade – In support of enabling Proxy Capability, this multi-purpose pattern can be used to establish (within the original service logic) a façade layer of processing that acts as a liaison between the original service and the new service. The façade component may actually invoke the corresponding capability on the newly created service, thereby acting as its service consumer on behalf of the consumer of the original service.
When applying these two patterns together with Service Decomposition, the façade logic can also be designed to compensate for a change in behavior that is likely to occur as a result of physically moving a segment of the original service logic into a new location.
An important requirement for the decomposition of a service to be successful is that the resulting, more fine-grained services have distinct functional contexts. When modeling and designing these new services, all applicable service-orientation principles and patterns must be considered as with any other new service. Other fundamental patterns, such as Service Normalization, also need to be applied to ensure that the new services properly line up with the others in the existing service inventory.
One common problem with post-implementation service decomposition, however, is that a given set of capabilities may not correspond cleanly to the functional contexts of the new services. What this means is that a new service may only require a portion of what the original service capability represents.
There are several ways of dealing with this, including a hybrid application of the Proxy Capability pattern where the original service retains some of its logic but then still calls a new service for the portion that now belongs elsewhere. However, there is yet another pattern we can take into account early on during the initial modeling stages of the original service in anticipation of future decomposition requirements. This pattern is called Decomposed Capability and it essentially asks us to think ahead as to how a given coarse-grained service context can be split into multiple finer-grained contexts and to then align the initial service capabilities correspondingly.