Question Details

No question body available.

Tags

architecture python

Answers (2)

August 9, 2025 Score: 4 Rep: 87,101 Quality: Medium Completeness: 60%

Its fine.

The problem is when you have multiple services and end up with a circular dependency, the no service injected into another service rule saves you from that ever happening

eg

MessageService -> ChatService -> MessageService

When you have lots of "Services" this can happen quite easily. But if you want you can add multiple layers of services and just make the rule, no dependencies on the same layer services

for example, the classic three layers (lets not get into what three tier realy means)

Application
Service
Data

can be expanded as much as you like

Application
Use Cases
Service
Low level service
Data

This let you keep the simple rule "don't depend on things in the same layer" while taking into account that "Services" can cover a whole bunch of stuff some of which might want to depend on each other.

You can now just make some "Services" "Low level Services" or "Use Cases"

August 10, 2025 Score: 4 Rep: 222,571 Quality: Medium Completeness: 50%

No this is obviously not a violation of the three-tier architecture (though I guess you really meant three-layer architecture, does not really matter). This kind of layering tells you only how to structure your application horizontally (i.e. Presentation layer - Business/Service layer - Persistence/Data layer), and still allows all kind of dependencies inside a single layer like the service layer.()

Still, horizontal layering is only one way to structure a system. Larger systems will usually also be partioned vertically. This often means multiple different applications, and/or multiple different (micro) services. Note the term service here does not refer to a single module inside a business layer, it refers to a fully self-contained web service which can be deployed and run on its own.

So in a microservice architecture, there might be a separate message service and a separate chat service - which are both web services. If you choose to design the system this way, then injecting the chat service module into the message service module would be an architectural violation, the only communication allowed between the two services would be using their web API.

Of course, vertical partioning of an application does not necessarily mean "micro services". Such structures can also be established inside monolithic applications, especially in larger ones. You can define an architectural rule that certain services belong together, and others should stay separated. Note that I emphasized above that this is your - personal - decision. There is no rule or law, not even a "best practice" which says that a system will become automatically "better" that way - whatever "better" means. Still, the larger the application gets, the more helpful additional structures become, because they allow different team members or different teams to work on isolated parts of the system, where changes to a module have a lower risk of breaking something unexpected.

On the other hand, imposing a vertical partioning on services which effectively need each other can lead to overengineering - more boilerplate code, more management effort than necessary - this is always a trade-off. In your specific case, as long as you do not have two different teams working on the message and the chat service, I would not overthink this and go ahead with injecting the second one into the first.

()In some articles or textbooks, the terms horizontal and vertical layers are used in the opposite way as I do. I use them with the direction of the "cut lines" between the layers in mind, presentation layer at the top, data layer at the bottom, like it is done here, and not with the relative position of the layers to each other.