From an architectural perspective, the API endpoint for invoking a price-drop should be moved to ProductsService. This would allow us validating the desired productId and ensuring that the product actually exists (without calling a sibling service or building a HTTP monolith).
However, addressing this would result in removing the entire PriceWatcherService from the sample.
Hey @ThorstenHans,
After having a look at PriceWatcher, ProductsService, and PriceDropNotifierService, I'd change the architecture in the following way:
The PriceDrop endpoint will be moved to the ProductsService as discussed.
The PriceWatcherService currently has the Register endpoint. I'd probably move that to the PriceDropNotifierService - when registering, it could call into the ProductsService to verify that the Product-ID exists. Alternatively, we could also move this endpoint to the ProductsService and leave the PriceDropNotifierService as it is - a simple I/O service that listens to a message broker and creates emails, if you prefer that. But maybe the first approach should be preferred as you can also implement a traditional endpoint in your second block when giving a talk.
From an architectural perspective, the API endpoint for invoking a price-drop should be moved to ProductsService. This would allow us validating the desired
productId
and ensuring that the product actually exists (without calling a sibling service or building a HTTP monolith).However, addressing this would result in removing the entire
PriceWatcherService
from the sample.WIP