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