Dynamics Retail Discount Extensibility Overall Approach
I have covered extensively on retail discount design. Think of my past posts as a build-up to Dynamics Retail discount extensibility.
If a partner want to replace Dynamics Retail discount engine, they can do so already with Dynamics Retail commerce runtime framework. If that is your plan, you can stop now.
Our goal from the beginning has been to help as much as we can, meaning partners do not have to rebuild everything from ground up and they can leverage existing discount engine features and build on top it.
The overall approach is a bit dry and we will explore details in subsequent posts.
Fine-grained extensibility
For small services, we can refactor the operations so partners can customize any of them. That is the approach with our commence runtime service customization. Discount engine extensibility functional requirements are more fine-grained. For examples,
- Additional discount line filtering. For example, you want to add inclusive/exclusive flag.
- If you add a new discount type, then it is a knapsack problem if it competes with other discounts.
As such, we are taking a different approach. In short, at the beginning of customized pricing service call to calculate discount, you can register your new discount type, and other customization. During the discount engine execution, it would use the registered implementation; if none, it would get the default.
public class PricingServiceSampleCustomization : IRequestHandler
{
public Response Execute(Request request)
{
// Register customized components here.
if (!PricingEngineExtensionRepository.IsInitialized)
{
PricingEngineExtensionRepository.RegisterRetailDiscountStore(new CustomizedRetailDiscountStore());
PricingEngineExtensionRepository.IsInitialized = true;
}
...
}
}
Built-in concurrency models via configuration 
We can group discount extensibility scenarios into three buckets: Concurrency model, new discount types and small changes, where concurrency model is the most complicated. In the beginning, we were thinking of enabling the customization of the concurrency model: you can interpret priority in your own way, and you can decide which discount types executes first, which ones later. During the internal review process, we realized that it was too complex, even for our own team to understand. To simplify it for the partners, we decided to implement a new concurrency model: compete within priority and compound across priority, in addition to existing pricing zone model. Customer would select a model via configuration. For now, no customization on concurrency model. We may add a new model in the future and we are open to revisit the decision and adjust as we go.
New discount types
With the concurrency model freeze, partners can focus on creating new discount types, and modifying existing discount types. We will explore this in details later.
Pre and post discount calculation
For example, partner can add code that would reset discount base amount for some items before discount calculation. By default, discount base amount is the price.