How to deal with cyclic dependencies?

[shwetakawale]

There could be situation like
Module A (Order) depends on Module B (Inventory):
Whenever a new order is placed, Module A needs to call Module B to check if the required inventory is available.
Module B (Inventory) depends on Module A (Order):
Module B needs to be notified when an order is placed, updated, or canceled so it can adjust inventory levels accordingly.

but in spring modulith it leads to cyclic dependency, there could many such usecases, is there any way to solve this @odrotbohm

[aahlenst]

High coupling of two modules either indicates that they should be a single module or that design needs to be improved. To break the cycles, you have two options: Introduce a third module that depends on the first two or move classes around. In this case, you could remove the dependency from Order on Inventory. If Inventory is notified of new orders anyway, Inventory can call Order directly to cancel the order if the required inventory is unavailable instead of Order asking Inventory whether there is enough stock.

[odrotbohm]

Sometimes you can invert the dependency by introducing an interface on the one side that's implemented by the other. So the former requirement might be inverted by introducing a StockAware in the order module that the inventory implements.

[felix2000jp]

Hi, I have been searching around for a solution to a question I am have related to this inversion of dependencies and since this is kind of related to it I am going to ask here.

I have a very similar situation to what you shared in the comment. I have multiple modules, but most importantly: A and B. Module A is a shared module and will be used by every other module in the application. It also has an interface whose implementation is at module B, just as described above, so it does not break due to cyclic dependencies.

My question is about application tests and the shared modules values on @Modulithic annotation. Module A is supposed to be shared, but now, because module B has the implementation of an interface of A, it too must be shared, even though the only thing relevant to module A (and every other module) is the interface implementation. So my question is: is making module B shared my only option here? Is there a way to define at module A (or somewhere else) that there is a dependency on specifically the implementation at B without making the entire module shared?

Sorry for the long text but I find it hard to explain my question without all context above.
Thanks for the help!

[aahlenst]

@felix2000jp If you feel you need to open up a module just because of X, then X is probably not in the right place. Why is the implementation in module B in the first place? If every module depends on A and the interface is in A, then the implementation should probably be in A, too. If it is due to some layering rules, providing an alternative implementation for testing purposes in A or creating some type of mock in every module might be a good (or even better) option, too.