-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fire event on inventory stock change #252
Comments
Requires move of inventory to a service instead of a repository. Can't really use Spring Data domain events as whether the events should be thrown depends on some configuration of the quantity threshold and we cannot inject a configuration properties type into an entity. Possible solution: inventory private event that signals every quantity change and an internal event listener that translates that into a threshold deceeded event. |
Decreasing the quantity of an InventoryItem now results in an internal QuantityReduced event being published. That is listened to by InternalInventoryListeners and verified against the threshold quanity defined via salespoint.inventory.restock-threshold (defaulting to Quantity.NONE). In case the current quantity is below that threshold a publicly consumable StockShort event is published that can be used to trigger further logic. Slightly tweaked the arrangement in Inventory event listening. The event types are now member classes of InventoryEvents. Listeners are grouped into InventoryListeners and the actual business logic executed for the OrderCompleted and OrderCanceled events has been moved into an internal InventoryManagement. Tweaked the Moduliths setup to always include the quantity module so that the Spring Boot type binding can be used in InventoryProperties. Had to let QuantityFormatter implement Converter as well and be annotated with @ConfigurationPropertiesBinding to be picked up. AbstractEntity now exposes ….hasId(…) for easier comparison.
Missing license headers or updates to those. Trailing whitespace.
Letting QuantityFormatter implement Converter<String, Formatter> will cause the instance not registered as a formatter anymore for the following reason: - Spring Boot's WebMvcAutoConfigurationAdapter.addFormatters(…) calls ApplicationConversionService.addBeans(…) - That in turn uses an if-*else*-cascade to register the found beans in the Formatting registry. If the bean implements Converter, it will not see the call to ….addFormatter(…) anymore. This has been filed in spring-projects/spring-boot#23576. As a workaround we now register a separate converter implementation that delegates to the formatter.
This is useful to implement automatic triggers of re-stock, e.g. by creating a supplier order or the like.
The text was updated successfully, but these errors were encountered: