Is it an anti pattern to have service to service dependency in the layered architecture? [duplicate]

Question

Is it a bad practice (or maybe anti-pattern) to have service to service dependency in the layered architecture? I've noticed that when an application is designed in a way that a service can call another service that carries the business logic it becomes very complicated and quite challenging to extend an enterprise application.

Imagine there are below layers:

Controllers:

• Controller A
• Controller B

Services:

• Service X
• Service Y
• Service Z

Repository

• Repository K
• Repository M

For example, Controller A > Service X > Repository K is a valid dependency, but Controller A > Service X > Service Z> Repository K seems to be not a good practice as it can become quite complex to extend after a while. So basically, Controller A > Service X > Service Z> Repository K can be broken down into Controller A> Service X> Repository K and Controller A> Service Z> Repository K. I suppose this may add a bit overhead at first but seems to be a better practice when it comes to the layered architecture. I was wondering if there is any pattern or best practices to support this.

Answer 1

Its not an antipattern but you are right to be warey of the complexity.

Consider for example one of your repositories might actually be a service, or one of your services might use a third party service.

You generally want to add abstraction layers where they encapsulate functionality and in a micro service setup that abstraction is microservices.

However, a clear anti-pattern would be having a circular reference, or perhaps skipping layers of abstraction, having sub services make the same call to another sub service rather than sharing the result.

If you keep the services small and focused and keep the relationship going in one direction you, the number of services shouldnt be a problem in of itself

Answer 2

Services calling services is indeed not an antipattern, but it is also not what you want to do due to the increasing complexity.

But sometimes you need results from different services into one controller, for example when you have 'Students' and 'Courses' combined into a controller which shows the courses followed by a student. In such cases, I tend to create a layer between the controllers and the services, named 'orchestrations'. Then the controller depends only on an orchestration, and the orchestration takes care of combining (or depends on multiple) services. But take care: if an orchestration depends on more than three services, then the design might not be the right one.

Answer 3

Taking an example of Order micro-service.

1. Order microservice doesn't only have Order Controller - > Order Service - > Order Repo

2. It will contain controllers, services, repos pertaining to the su module within the order module.

3. Interaction between submodules via Services are bad? No, Infact services are reusable piece of code designed for the purpose.

In short, service to service calls is not an anti-pattern in general. However it can become an anti-pattern if submodules & the respective service are not identified & defined properly.