Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Best way to implement complex business rules  RSS feed

 
Svante Paldan
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

I have been faced with an architectural decision which I can't really figure out how it's best solved.

Let's say we're developing a e-commerce system, like eBay. (This is actually fictional, just to give a comprehensible example)
Customers are divided into groups depending on if they are free members or if they are paying, Premium, members.
Depending on which group a customer belongs to, different pricing models are applied.
Some examples:
- A free member can buy without charge for up to $20 (Initially), after that each transaction costs $.1, premium members have no such limits.
- Premium members sell items for a charge of $.5 while free members are charged $1
- When a free member has achieved some target X, his "credit limit" on buys are raised to $50, at target Y it's raised to $100 etc.
- At the same time, we might apply floating costs depending on the buy/sale amount to both premium and free members.
- We might also apply different rules, like coupons etc., upon registration depending on the membership type. (We might even have two completely different registration ways)

All of these amounts will change as the business evolves, we will also be adding further membership-levels as we go. Membership types will not be applied only to doing transactions but will also affect other types of costs and features.

Currently we have a pure EJB3 system running on JBoss 5 with a MySQL database server.
We have the business rules implemented by Session Beans, with Entity beans for data persistence and a JSP-frontend (which will be gradually moved to Struts or Seam as we find the time).

I have been considering some approaches, but feel that they are all lacking in some aspect, for example:
- Trying to abstract some of the "applyPricing" rules into a Rule class that can be moved around and used in different parts of the business layer to apply whatever rules apply for the customer type at hand. (Or even DI the object) This has the advantage that it's rather quick to develop and all membership-level-rules are kept together and not sprinkled all over the place. It has the disadvantage that it's really hard to keep a nice flow of information if some "perform Buy" method needs to pass data back and forth to such rules.

- Sprinkling the relevant places of the business layer with if/else or switch/case blocks to apply rules depending on which membership type the user currently doing a transaction has. This is really quick to develop. It does has the huge disadvantage that it's quickly going to be unmaintanable and changing one rule might cause the developer to chase around 14 places to update the rule according to business requirements, this also makes it very prone to errors.

- Using a Business Process Modeling framework like JBoss jBPM. This has the advantage that (once implemented) will be very maintainable and extremely easy to configure and extend as we add further membership types. It does have the disadvantage that we need to learn a new framework and try and cram it into our current architecture (which I can only imagine includes poking around a lot of XML). At least jBPM seems complex to integrate with EJB 3.

We have limited resources (and time) available so speed and ease of development is a high priority, however I still need to secure maintainability and configurability as well as extensibility.

I guess this is an issue that has been solved over and over again by architects and developers.

Anyone care to share their experiences and knowledge?

Best Regards,

Svante Paldan
 
Ulf Dittmer
Rancher
Posts: 42972
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One central place to keep the rules is definitely the way to go. I'd shy away from using something like jBPM; it doesn't sound like the problem is complex enough to justify the up-front investment in learning it; that might be different if it was in use in the project already.

To keep things changeable, I might opt for writing the rules as JavaScript code, and having that executed by the Rhino library. That would enable you to upload a new version of the file containing the rules, and just clicking "Refresh rules" in the admin GUI if the rules change - no web app restart required. Rhino can compile code to classes, so it is subject to HotSpot compilation to native code; I'm mentioning that to address the performance problem many people would suspect a scripting solution to have.

My preferred approach would actually be to keep the relevant information in the DB, and add a little web app to configure it, but it sounds as if you're a bit time-constrained, which may rule this out. Plus, such rules tend to change in little ways that are hard to code into a DB, but which would be easy to add to a JavaScript file.

It has the disadvantage that it's really hard to keep a nice flow of information if some "perform Buy" method needs to pass data back and forth to such rules.

I'm not sure what you mean by this, so maybe I'm missing this perceived drawback.
 
Svante Paldan
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let me try and explain what I meant by a really simplified example which I'm not sure if it makes sense in reality :-)

Say I'm starting some "doBuy" and I want to keep track of a total cost of the transaction.
The total cost is calculated by applying ruleX-Y-Z given some input parameters (membership type for example) .
Well sure, I could just have those rules return "This is how much my cost is" and then add them up at the end.
But what if I have a number of these things that I need to poke around with, add, subtract, use as input parameters to a subsequent rule in the more general "doBuy" flow?
 
Ulf Dittmer
Rancher
Posts: 42972
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wouldn't all that be part of the rules, and thus implemented in the one central class (or script)?
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!