Storing self-referencing application logic functions in Mongo and running them?

[fuzzybabybunny]

I'm making a web store in Meteor and I've got a collection called Discounts in MongoDB and each document contains info for a different discount / coupon code.

I came to realize that applying a discount code to someone's order isn't that straightforward - there needs to be a way to determine if the discount is valid or not, and it would be amazing if the ability to check validity was stored right in each separate discount object itself. There could be a huge range of different discounts, each with a different "rule" for determining validity, and it doesn't always make sense to store the rules separate from the discounts.

I want each discount object to contain a function that takes the customer's order form data (things like order date, total price, customer's email, etc) and checks it all to see if the conditions are valid for applying the coupon code.

If so, it'll return a discount. If not valid, it won't return any discount.

// if the customer's order contains RAM and is in 2015, they get $100 off
{
  sku: 'RAM-50-2015',
  discountAmount: -100,
  discountCode: 'SAVEONRAM'
  check: function(orderFormContents) {
    if (orderFormContents.ram && orderFormContents.year === 2015) {
      return this.discountAmount;
    } else {
      return "order not valid for this coupon"
    };
  }
}, {
  // If the customer's order is in Oct 2015 with at least $100 in total price, they get 20% off their order
  sku: 'OCT-2015-Promo',
  discountAmount: -0.20,
  discountCode: 'OCTSAVINGS',
  check: function(orderFormContents) {
    if (orderFormContents.totalPrice >= 100 && orderFormContents.month === 10 && orderFormContents.year === 2015) {
      return orderFormContents.totalPrice * this.discountAmount;
    } else {
      return "order not valid for this coupon"
    };
  },
}, {
  // If the customer has any credits in their account, they can be applied via a coupon code
  sku: 'CustomerCredit',
  discountAmount: function(email) {
    return db.Customers.findOne({
      email: email
    }).creditAmount;
  },
  discountCode: 'CUSTOMERCREDIT',
  check: function(orderFormContents) {
    var customerCredit = this.discountAmount(orderFormContents.customerInfo.email);
    if (customerCredit > 0) {
      return orderFormContents.totalPrice - customerCredit;
    } else {
      return "You have no credits in your account."
    };
  }
}

I know that Mongo is primarily a data store and should not be used for storing and calling functions for application logic:

http://docs.mongodb.org/manual/tutorial/store-javascript-function-on-server/

However, using system.js outlined in the docs above seems really, really cumbersome, especially since the functions won't be able to utilize this like in my examples above to reference the objects that they're currently inside.

I'm hoping that there's an easier way to store self-referencing functions inside objects and then run them when I need them?

 

[DaveSimmons]

Note that you still need some overall controlling logic to check for conflicts between the discounts, otherwise you might accept 10% off, 15% off and 20% off coupons for the same order. You might intended that all coupons expire separately then mess up and have overlapping date ranges.

If you use the self-contained logic by itself you could limit customers to one discount per order.

 

[fuzzybabybunny]

Note that you still need some overall controlling logic to check for conflicts between the discounts, otherwise you might accept 10% off, 15% off and 20% off coupons for the same order. You might intended that all coupons expire separately then mess up and have overlapping date ranges.

If you use the self-contained logic by itself you could limit customers to one discount per order.

Very good point.

Are there any patterns or ways I should be modeling a discount coupon system then? To have a combo of external checks and internal checks?

 

[purbeast0]

why not have a discount document in the mongo table and just have the discount on the order check if it exists in the db, and if it does, verify that it meets all conditions?

then just have a job on the server that runs daily that will expire coupons once the date passes when they are no longer valid?

 

[fuzzybabybunny]

why not have a discount document in the mongo table and just have the discount on the order check if it exists in the db, and if it does, verify that it meets all conditions?

then just have a job on the server that runs daily that will expire coupons once the date passes when they are no longer valid?

Would the conditions themselves be stored in the discount document itself as well?

 

[fuzzybabybunny]

This can be quite complicated IMO. Say that you were coding a backend system where a user can create a custom discount code with numerous custom conditions and discount amounts that could change based on which or how many conditions are fulfilled.

You have each individual condition, and then AND / OR, then you have the different formulas for calculating discounts depending on how the conditions get evaluated.

 

[purbeast0]

This can be quite complicated IMO. Say that you were coding a backend system where a user can create a custom discount code with numerous custom conditions and discount amounts that could change based on which or how many conditions are fulfilled.

You have each individual condition, and then AND / OR, then you have the different formulas for calculating discounts depending on how the conditions get evaluated.

still doesn't change the fact that you can store all of that in a discount document and have the conditions in there.

then just check if the conditions are met when the user goes to pay.

what the conditions are really irrelevant as long as you check against them when the user goes to checkout. if they match, apply the coupon. if they don't match, the coupon is invalid for the order.

 

[Dissipate]

I used to work on a retail-based ERP system that had to support discounts based on promotion codes at checkout. The problem was that the business logic for these promo codes were constantly changing (e.g. if the customer checks out with a Coogi item on the 3rd Wednesday of the month, give them a 10% discount). We had a logic system to make the business logic more flexible, but it was still quite inflexible as to what conditions it would support.

It was actually after I left that job that I found out that what they needed was a rules engine. A rules engine is exactly what is good for this situation:

The expression of arbitrary, frequently changing business logic is a major source of complexity. Clara aims to rein in this complexity by untangling business logic, expressing it as composable rules while...

https://github.com/rbrush/clara-rules/wiki/Introduction

The rules engine Clara is written in Clojure, so you probably need something else. But it is a good example of what you should be looking for.

You add/remove rules on the fly, then just pass your data through the rules to see what matches. In your case, once your rules engine is set up, you wouldn't store actual code (which is a major security nightmare waiting to happen BTW), you would just store the simple rules, then load them into memory to check an order against at checkout.

 

[fuzzybabybunny]

I used to work on a retail-based ERP system that had to support discounts based on promotion codes at checkout. The problem was that the business logic for these promo codes were constantly changing (e.g. if the customer checks out with a Coogi item on the 3rd Wednesday of the month, give them a 10% discount). We had a logic system to make the business logic more flexible, but it was still quite inflexible as to what conditions it would support.

It was actually after I left that job that I found out that what they needed was a rules engine. A rules engine is exactly what is good for this situation:

https://github.com/rbrush/clara-rules/wiki/Introduction

The rules engine Clara is written in Clojure, so you probably need something else. But it is a good example of what you should be looking for.

You add/remove rules on the fly, then just pass your data through the rules to see what matches. In your case, once your rules engine is set up, you wouldn't store actual code (which is a major security nightmare waiting to happen BTW), you would just store the simple rules, then load them into memory to check an order against at checkout.

Ah, gotcha. I'll read up on it. I was initially thinking I needed to build up a Truth Table or something.

Rules Engine. Interesting...

 

[fuzzybabybunny]

I used to work on a retail-based ERP system that had to support discounts based on promotion codes at checkout. The problem was that the business logic for these promo codes were constantly changing (e.g. if the customer checks out with a Coogi item on the 3rd Wednesday of the month, give them a 10% discount). We had a logic system to make the business logic more flexible, but it was still quite inflexible as to what conditions it would support.

It was actually after I left that job that I found out that what they needed was a rules engine. A rules engine is exactly what is good for this situation:

https://github.com/rbrush/clara-rules/wiki/Introduction

The rules engine Clara is written in Clojure, so you probably need something else. But it is a good example of what you should be looking for.

You add/remove rules on the fly, then just pass your data through the rules to see what matches. In your case, once your rules engine is set up, you wouldn't store actual code (which is a major security nightmare waiting to happen BTW), you would just store the simple rules, then load them into memory to check an order against at checkout.

Node-Rules seems pretty promising for my application?

https://github.com/mithunsatheesh/node-rules/blob/master/examples/2.MultipleRules.js

 

[Dissipate]

Node-Rules seems pretty promising for my application?

https://github.com/mithunsatheesh/node-rules/blob/master/examples/2.MultipleRules.js

Yep, looks like a good place to start!