Re-architecture PriceWatcher and PriceDropNotifier

[thorstenhans]

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

[feO2x]

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.