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:


  • Controller A
  • Controller B


  • Service X
  • Service Y
  • Service Z


  • 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.


3 Answers 3


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

  • One challenge I have noticed is some times trying to keep relationship in one direction can make the controller to become quite fatty. Of course, it does not contain the business logic, but there will be a lot of code to pass objects among different services and probably address the required transformations, etc.
    – Ali
    Aug 4, 2020 at 14:49
  • I guess its always a question of what logic belongs in a controller. if you pass everything to a service, then the service is just your new controller right. So some orchestration in the controller is the right place for it.
    – Ewan
    Aug 4, 2020 at 15:24

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.


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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.