Logic centralization pattern
In the case of agnostic services—those containing reusable logic[5]—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.
This approach requires an enterprise-wide standard to enforce the centralization of logic.
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.
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.
Instead of using the existing red service, Project Team 1 creates a new redundant red service to better align with their short-term requirements.
With an enterprise-wide design standard in place, access to the redundant red service created by Project Team 2 is restricted, ensuring that service consumers use the existing red service developed by Project Team 1. Additionally, Project Team 3 is prevented from creating a new service with overlapping functionality and instead contributes to the evolution of the existing red service.