This is one example for MVC structure:

View layer -> Controller layer -> Service layer -> Repository layer
View layer -> Controller layer -> Repository layer

In general approach if you need to do some simple data query your Controller layer can call Repository layer directly.

And this is all fine at the beginning. When code and logic start to grow there will be an issue that some services need to share the same logic. If we put the this logic in one service other services need to call this service and we get this scenario:

View layer -> Controller layer -> Service layer -> service layer

And for me this is a bad practice because this can lead to circular references e.g. service1 -> service2 -> service1, especially if you are using dependency injection container.

One solution for this will be to introduce one extra sub layer and put common logic there, e.g.

View layer -> Controller layer -> Service layer -> Sub layer

The problem with this is what naming conventions to use and how to name the classes in this sub layers when code starts to grow and number of those sub layers starts also to grow? Or maybe there are some other techniques for dealing with this problem?