Logic Centralization is a design pattern, applied within the service-orientationdesign paradigm, whose application aims to increase the reusability potential of agnostic logic by ensuring that services do not contain redundant agnostic logic and that any reusable logic should only be represented by a service that has the most suitable functional context.
Rationale
As more and more services are developed, there is a constant risk that services with redundant functionality may be created. Although the application of the Service Normalization design pattern does help to eliminate this redundancy, however, just by having a set of normalized services on its own, does not guarantee that they would be reused as originally envisaged. In case of agnostic services, this issue can severely restrict the actual reuse of such services because a project team may decide not to reuse an existing service, e.g. it requires data that corresponds to a complex schema, and instead develop a lightweight service that just does the job. As a result, the same reusable logic now exists with two different services, whereas the existing service should have been evolved even if it did not contain the most suitable flavor of the functionality. This effect gets multiplied when another teamhoping to find the functionality within the existing service, as the boundary of the service does cover the required functionality, fails to find it and instead start using the newly created service by Team A. Consequently, the actual reusability of the original agnostic service drops and at the same time creates governanceproblem as far as the maintenance of the original and new services is concerned because now reusable logic exists in a decentralized manner. In order to ensure that a particular type of reusable solution logic is only enclosed by one specific agnostic service, the Logic Centralization design pattern dictates that design standards need to be established that force the proper use of agnostic services. This gives the service consumers the confidence that they are accessing the functionality through the correct service.
Usage
The application of this design pattern requires setting up 'official endpoints' that represent a particular type of functionality i.e. the functionality that falls under a particular type of functional domain. Access to any other services, which may offer the same functionality, is prohibited and only one service is made accessible for a particular type of functionality. By restricting access to other services, the governance burden is reduced as now the logic is confined within a single service. Whenever a new functionality is required, which is not currently offered by any of the existing services, then first the functional contexts of the existing services need to be checked and if the new functionality falls under the boundary of an already existing service, then it should be added to that service. This requires an enterprise wide standard that enforces the centralization of logic. In order to make sure that service developers are aware of the service boundaries, Metadata Centralization design pattern could be applied. This helps in creating a centralized repository of information about the functional contexts and the functionality provided by the services. The Logic Centralization design pattern when applied together with the Contract Centralization design pattern, constitute the Official Endpoint design pattern. The application of the Logic Centralization design pattern further helps in the application of the Service Reusability and the Service Composability design principles by ensuring that each service contains the right type of reusable functionality so that it can be composed repeatedly.
Considerations
In order to apply this design pattern, it needs to be ensured that all the project teams across the enterprise understand and agree to the proper use of agnostic services and do not create any new services that only serve the short-term requirements of a project. This can also impact the project delivery times as the use of existing agnostic services would require increased time and efforts. This is because the services in the current project may not be able to make use of the agnostic services until their own design is changed.
