Using delegation to separate layers

Question

We refactored a Java app where the code was spilled all over and didn't follow even the most basic principles or patterns. We managed to extract the following layers:

• a data layer
• a repository layer with command and query repositories for each kind of db entity
• a service layer which works only with repositories and can have business logic too
• a service orchestration layer which does service composition in order to implement the business of the application (doesn't work with repositories)
• an API and a Controller layer for displaying the views, which should work only with orchestration services

There are multiple situations where a controller or the API needs to call a method from a service (service layer), but given our desire to have the controllers working only with orchestration services we are forced to create an orchestration service which doesn't do anything but delegates the method calls to the actual service.

Is this a correct approach, or should we remove the middle man (orchestration) when it doesn't do anything but delegation?

Best regards, Cristian.

Answer 1

If it were my code, I would prefer to follow a standard - even if the orchestration layer sometimes just delegates straight to the service layer. In the event that a business process changes, that change will hopefully be isolated to the orchestration layer, leaving the calling code unaffected by the change. In addition, if you're trying to enforce standards around code structure, be consistent about it, lest bad practice starts creeping in again. If you sometimes invoke the service layer directly, and at other times, go via the orchestration layer, it might just lead to confusion amongst developers in terms of which approach to use when.

Lastly, review the granularity of your operations - do certain method calls truly exist in complete isolation, or do they form part of a larger business process? I agree with your layering scheme - your presentation layer should know how to invoke a business process (exposed by the orchestration layer), but it should be ignorant of the details involved in executing that process (exposed by the service layer). Even if the business process consists of only a single step, it's still a business process that can be exposed by the orchestration layer - it just happens to be a very simple process.