To keep a nice and clean microservice architecture, we need an additional (Spring) web service that handles all promotion related data.
This means that it stores records for all existing promotions and provides an endpoint for providers to add new ones to the system.
Each promotion needs to be identified by a promotion ID that is passed to the runDeduct algorithm in deduct.DeductService and can be used to resolve the promotion that the user that caused the execution of runDeduct wants to take part in.
This resolution is required to let deduct.DeductService know which reward item to add to the user's basket or (in versions beyond Feb22) which other action to perform (e.g.. 30% off on the basket, ...).
Since the promotion service exists by now, we need to integrate the logic for communicating with basket/promotion service into the the deduct service to achieve the above behaviour.
To keep a nice and clean microservice architecture, we need an additional (Spring) web service that handles all promotion related data.
This means that it stores records for all existing promotions and provides an endpoint for providers to add new ones to the system. Each promotion needs to be identified by a promotion ID that is passed to the runDeduct algorithm in deduct.DeductService and can be used to resolve the promotion that the user that caused the execution of runDeduct wants to take part in.
This resolution is required to let deduct.DeductService know which reward item to add to the user's basket or (in versions beyond Feb22) which other action to perform (e.g.. 30% off on the basket, ...).