Circular dependencies working with events and agregate associations

[matses]

Hi there,

First of all thank you for your wonderful job on spring modulith, I'm testing it and really like the idea !

Just a question about working with events and aggregate association.

Let's say my app is a platform where you could buy or sell Pokemon cards. Catalog module represents all the cards declared in the platform. No inventory module needed : i just need to change the state of a product ("Available" to "sold") when a product is ordered . OrderService publishes an OrderCompleted event, and ProductService subscribes to OrderCompleted event to change the product state.

In this case we get :
Caused by: org.springframework.modulith.core.Violations: - Cycle detected: Slice catalog ->
Slice order ->
Slice catalog

A quick workaround to avoid these circular dep would be to move all the shared events (here OrderCompleted) in a dedicated shared module ( im not fond of this solution).

What is your opinion about this use case which looks pretty common ? Any chance cycle violations could be softened in some specific cases?

[JosRoseboom]

Hi matses,

Don't know if you are specifically aiming for an answer from @odrotbohm , but I can share my thoughts. The way I did that is by letting the decision to make a service call or listen to an event depend on the direction of the dependency.

In your case, Order depends on Catalog. Instead of publishing an event from Order, OrderService could call ProductService to update the status.

Conceptually, the catalog is only aware of the possibility of changing a state of a product. There's no need to know that this is caused by an order being placed.

If something happens to a product that the order should be aware of (say the price changes and this is relevant for pending orders), the catalog could publish an event that order listens to. That event resides in the catalog module that Order depends on, with no need for a shared module.

[odrotbohm]

This sounds like a very reasonable approach. The underlying questions you'd have to answer is why the catalog would have / want to know about the OrderCompleted event. A directed acyclic graph between modules is key to an evolvable architecture, i.e. in case you can avoid either reference, that'd be ideal. As a fundamental heuristic on which dependency direction is more directional, I usually ask: “Which of the two modules could exist without the other?”. A catalog makes sense in itself without any order logic on top of it. Orders without any products hardly make any sense (in this particular context at least).

That said, a common approach to resolve the technical dependency even in an arrangement such as the one described by the original poster, is to invert the dependency by introducing an interface on the catalog side for OrderCompleted to implement. That way, the catalog could listen to the interface it exposes itself and would still get OrderCompleted events submitted.

[matses]

Thanks to both of you for sharing your thoughts and tips !
A really interesting thread to improve my DDD way of thinking ;-)