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 protected]> wrote: > > Am 14.02.2013 um 14:00 schrieb Pascal Robert <[email protected]>: >>>> 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 protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/kenlists%40anderhome.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
