Circular dependencies working with events and agregate associations #493
-
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 : 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? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
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. |
Beta Was this translation helpful? Give feedback.
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 catal…