# Logic centralization pattern

Logic Centralization is a design pattern within the service-orientation design paradigm that aims to enhance the reusability of agnostic logic. This pattern ensures that services do not contain redundant agnostic logic and that reusable logic is encapsulated within the service that best aligns with its functional context.

## Rationale

As the number of services within a system increases, there is a risk of developing services with redundant functionality. While the application of the Service Normalization design pattern helps eliminate such redundancy, the existence of normalized services alone does not guarantee their intended reuse.
In the case of agnostic services—those containing reusable logic—this issue can significantly hinder actual reuse. For instance, a project team (Team A) may choose not to reuse an existing service if it requires complex data structures and instead develop a simplified service that meets their immediate needs. As a result, the same reusable logic becomes duplicated across multiple services, rather than evolving within the original service. This challenge is further compounded when another team (Team B) searches for the required functionality within the original service but, failing to find a suitable implementation, opts to use the newly created service by Team A. Consequently, the reusability of the original agnostic service decreases, and a governance issue arises due to the decentralized distribution of reusable logic across multiple services.
To mitigate this issue, the Logic Centralization design pattern establishes design standards that enforce the proper use of agnostic services. This approach ensures that a specific type of reusable logic is encapsulated within a single, well-defined service, thereby providing service consumers with confidence that they are accessing functionality through the appropriate service.

## Usage

The Logic Centralization design pattern establishes designated "official endpoints" (services) that represent specific functional domains. Under this approach, access to alternative services offering the same functionality is restricted, ensuring that only a single service is available for a given type of functionality. By enforcing centralized access to services, governance complexity is reduced, as reusable logic is confined to a single service instance.
When new functionality is required, an assessment is conducted to determine whether it falls within the functional boundaries of an existing service. If so, the functionality is incorporated into that service rather than creating a new one. This approach requires an enterprise-wide standard to enforce the centralization of logic.
To ensure service developers are aware of service boundaries, the Metadata Centralization design pattern can be applied, facilitating the creation of a centralized repository that documents functional contexts and service capabilities. Furthermore, when implemented alongside the Contract Centralization design pattern, Logic Centralization contributes to the Official Endpoint design pattern.
By ensuring that each service contains the appropriate type of reusable functionality, the Logic Centralization design pattern supports the principles of Service Reusability and Service Composability, promoting efficient service composition and reuse.

## Considerations

To implement this design pattern effectively, it is essential that all project teams within the enterprise understand and adhere to the proper use of agnostic services. Teams must avoid creating new services that address only short-term project requirements, as this can lead to redundancy and reduced service reusability.
The application of this pattern may impact project delivery timelines, as integrating existing agnostic services and evolving them in accordance with established guidelines requires additional time and effort. In some cases, services within a project may not be immediately compatible with agnostic services until their design is modified to align with the standardized approach.