oblique quest
Hey, posting hoping someone can shed some light on a back-end arch practice question
I’d like to clean up our structure because, over time, we’ve accumulated a ton of circular dependencies. results: ✖ Found 88 circular dependencies!
Current structure:
src/
use-cases/
amodule/
application/
use-cases/
domain/
infra/
a.controller/service/module.ts
bmodule/
...
b.controller/service/module.ts
• Ideally, our services only contain CRUD operations and a few utils.
• The rest of the business logic lives in use cases tied to the context, plus a set of more general use cases at the root.
we often end up in situations where one service calls another service for CRUD operations… and vice versa → hence the circular dependencies.
To keep imports one-way, I suggested creating new modules that regroup the use cases requiring two modules that currently reference each other. This new module would then be imported at the root of the project.
└─ imports: [CModule]
├─ declares: AController, BController
CModule
└─ imports: [AModule, BModule]
├─ provides & exports: AUseCase, BUseCase
AModule
└─ provides & exports: AService
BModule
└─ provides & exports: BService
We could also rely on an event system to reduce dependencies, but even though we sometimes use it already, we don’t really want to commit 100% to that approach.
Issues I’m facing
• My team is a bit reluctant regarding the amount of refactor work this would involve.
• Their position is basically: “as long as it works, it’s fine”, even if that means wasting more and more time dealing with circular dependency issues in module imports.
My questions
1. Do you think this approach is a reasonable first step to start cleaning things up? Are there cleaner options that solve the same problem? (Sources or references welcome!)
2. How would you bring this up to your team to actually move the topic forward?
pliant bluff