Re: Business rules and filtering
Re: Business rules and filtering
- Subject: Re: Business rules and filtering
- From: Ken Anderson <email@hidden>
- Date: Thu, 14 Feb 2013 09:09:58 -0500
I think the general idea of a line item for each discount is a good one - you have history and accountability should the need arise to investigate.
I think a rule engine is definitely the way to go here. I'm not sure how rule engines and general BPM flesh out, but my experience with rules engines is that you gain a lot of flexibility, albeit with some complexity. According to Wikipedia, Drools is somewhat in line with CLIPS, which is what I used a while back.
The nice thing about a rule engine is you simply assert all the line items as facts, and let the rule engine go. If the rule engine asserts new discount facts, those are applied.
While a rule engine may seem like overkill, it really isn't. If you have just 2 discount schemes that could possibly overlap, you already could use a rule engine. In the rule engine, it will be real easy to add new rules as you add new discounts, that make sure you can't apply 2 discounts that are not allowed to be available concurrently.
Ken
On Feb 14, 2013, at 8:35 AM, Maik Musall <email@hidden> wrote:
>
> Am 14.02.2013 um 14:00 schrieb Pascal Robert <email@hidden>:
>>>> In a shopping cart, how would you apply discount based on business rules? For example, if someone buy a quantity of 3 of the same item, you apply discount X, or if an item is ordered before a certain date, you apply discount Y. Yes, I can do that all in code, but that's not very flexible.
>>>>
>>>> Any ideas?
>>>
>>> Add an abstraction layer for shopping cart items and add virtual items to the cart that contain the calculated rebate?
>>
>> If I understand well, let's say I have "item.quantity()" with a value of 2. I then would have another EO related to this item for each quantity that a discount should be applied to.
>>
>> For example, item's name is "WOWODC 2013 ticket" and someone wants to buy two tickets. In "VirtualItem", I would have multiple rows for "WOWODC 2013 ticket", with a different quantity and discount for each row, so I would do a fetch « VirtualItem.NAME.eq("WOWODC 2013 ticket").and(VirtualItem.QUANTITY(2) » and apply the discount from the fetched row.
>
> The point of virtual items would be to not be persistent, and not introduce new relationships and persistence complexity.
>
> Obviously there are several ways to do that, and it depends on how you want to apply the rebate. Rebates generally could go per item, per item collection, or per purchase. If you tie the rebate logic to items only, you'll have difficulties applying a total rebate over the whole purchase containing all sorts of item types.
>
> My original thought would depend on the rebate stuff happening in cart summing. Iterate over items, and ask each item about it's effective price, so that individual items can return a rebated price based on their quantity() or other properties. Also, the cart could decide to apply a general overall rebate if certain conditions are met, like a membership.
>
> You would sum up both real price and effective price, and if they are different in cart sum, generate a virtual (non-EO) item that contains the rebate sum. Make an interface that the WOD's item display operates on, and let both real items and virtual items implement that interface. Then store the sums in the cart EO. Virtual items would just be re-generated whenever the cart is redisplayed.
>
> And that's just ONE way...
>
> Maik
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden