Next Question
RSS
Look into something called a "domain specific language", or DSL. When business rules get complicated and change often (which seems to be your premise), you'll make your life a lot easier by breaking them out and defining them in a way that makes it technology-agnostic (XML is a popular way, but really just depends on how willing you are to write parsers). Business rules are not invented by coders, they are invented by business people, therefore in the best situation you want to provide tools that your business person can use to update the ruleset.
So you create a "language" (not really as hard as it sounds, as it only encompasses the universe you describe), and then either write a tool to produce results in that language, or even if you don't do that, you've still made the training curve easier by providing a way to describe the rules in something other than Javascript or Python or what have you.
Next you need some sort of way to interpret your rules file. It should be dynamic, so you don't have to boot your server whenever the rules change. One nice option that some platforms provide is to integrate an interpreted language (like Ruby) directly into your code so that your rules themselves can be written in a full-fledged programming language. This gives your users great functionality in writing a rule (for instance, math and variable functions), and really all you have to do is "execute" the rule using the built in interpreter. Java+Ruby=JRuby is a great example of this.
It's really a fairly long topic to get into here, but if you dive in you might find that you like it. I'm a big believer that the business logic should stay as far away from the code as possible, so DSLs make a great deal of sense to me.
If that's too big an undertaking, then ask yourself whether the rules can be parameterized, as in your example. Maybe you leave the rule hardcoded (for now - never a permanent answer!) but put the variables that rule depends on into the database, with a way for the business person to set those. You should never ever have to go through a code deploy (you do have a whole lifecycle that includes source control checkins and unit testing, right???) just to change a single number or two.
Source(s):
http://en.wikipedia.org/wiki/Domain-specific_language
http://msdn.microsoft.com/en-us/library/bb126235.aspx
Written a bunch myself, from the guts of a natural language search engine to a logical CSV validator.
Permalink | Report
Even if the rules change, if you're the one that will have to change them, the best and easiest way to do that is in source code if you know the language.
Just make sure you do it in a way that is easy to read, use comments and descriptive variable names
Maybe you can put common variables that are susceptible to change in a database and connect it to an easy to use front end.
But when it comes to the actual logic, I think hard coding will save you a lot of headaches.
Update:Ideally you should have the business logic in a separate file or library, that way it's easier to maintain, update etc.Here's an article I've found on The Daily WTF that should be an interesting read: http://thedailywtf.com/Articles/Soft_Coding.aspx
Permalink | Report
Beyond the code, the key to solving your problem really comes down to documentation. No matter how you code the solution to this problem, documenting what and why you did it will be very (very) important.
Personally, I use a combination of block diagrams, inline comments that refer to those diagrams, and text to add additional information to the diagrams. This combination has proven to be exceptionally useful and helps everyone (not just programmers) understand the flow of information through a complex system. If you'd like an example of my block diagrams, etc, just ask and I'll whip up a sample in a reply.
Taking the time to compose what feels like a manual at this stage will not only help you get your head around complex rules, but it will allow you to "pass the buck" up to the folks who define the rules. They can approve and add / change rules whenever they would like. I find that leaving this sort of stuff up to the "suits" always frees up development time.
2) CONCEPTUAL CODE
As you know (because your worried about it), simplicity is key. Without completely understanding your problem, I would likely create a unique validation class. Inside of this class, every option and variable would exist. This is similar to the DSL method that Shakespeare mentions but while DSL is common with high level business and project management folks, classes are universally known by all professional programmers. The other benefit of building a class is that it is easy to insert other required scripting or validation functions within it.
3) WRITING IT
If this is a web based application built out of PHP, mySQL and Javascript, here is what I would do: After the user entered data, I would use javascript to check the validation rules. Then on Submit, I would validate the entries again with PHP. Importantly, I would perform one last check after the data had been cleaned (for security) before the data was insert into the database.
This 3 tiered method would ensure that the correct data entered the database. The only way that data could be entered incorrectly would be due to validation rules that are not defined.
I hope that this helps, Darth!
Source(s):
I'm a professionally trained programmer in a few different languages with years of experience.
Permalink | Report
Another thing is don't try to cram all of the rules into one model. You need to look for patterns, maybe you have two or three types of rules and you can use that to design the structures used to store and read them.
Don't worry about adding complexity, because this is work that is going to pay itself after the first 2-3 times that you have to go back and change a date or an amount simply because the customer either changed her mind or there was a typo in the spec documents.
Some examples of rules we were able to implement:
1. Minimum and maximum dollar figures used to select a commission rate.
2. Arbitrary month periods with variable start/end dates.
3. Variable workflows, where answering with a specific value forces events to be called in different order.
Permalink | Report
Answered Question
M$2
January 21, 2009 02:48 PM
Validating business rules, what would you suggest for this situation?
I'm working with a UI which has a bunch of business rules hard-coded.
For example, if a user selects option A then rule X applies. On the other hand if they choose option A and B, then rules Y and Z apply. Option A and B means rule Z only applies but only on Sunday (get the drift?!).
I'd like to get away from hard-coding like this but I'm not sure what would be an effective way to do so. Part of the complication is that the rules can change periodically. For example a dollar amount threshold associated with rule Y above might change from $0.01 to $1.05 or something similar.
Should I try to describe these rules in a database table or two and create some function which takes the parameters and returns the "sum" of the application of the rules?
Looking for some ideas, particularly if you've conquered this type of problem yourself.
For example, if a user selects option A then rule X applies. On the other hand if they choose option A and B, then rules Y and Z apply. Option A and B means rule Z only applies but only on Sunday (get the drift?!).
I'd like to get away from hard-coding like this but I'm not sure what would be an effective way to do so. Part of the complication is that the rules can change periodically. For example a dollar amount threshold associated with rule Y above might change from $0.01 to $1.05 or something similar.
Should I try to describe these rules in a database table or two and create some function which takes the parameters and returns the "sum" of the application of the rules?
Looking for some ideas, particularly if you've conquered this type of problem yourself.
Interesting Question?
Yes (1)
No (0)
- In Web Development |
- |
- Report |
-
Share
RSS
Best Answer Chosen by Asker
| January 21, 2009 03:46 PM |
So you create a "language" (not really as hard as it sounds, as it only encompasses the universe you describe), and then either write a tool to produce results in that language, or even if you don't do that, you've still made the training curve easier by providing a way to describe the rules in something other than Javascript or Python or what have you.
Next you need some sort of way to interpret your rules file. It should be dynamic, so you don't have to boot your server whenever the rules change. One nice option that some platforms provide is to integrate an interpreted language (like Ruby) directly into your code so that your rules themselves can be written in a full-fledged programming language. This gives your users great functionality in writing a rule (for instance, math and variable functions), and really all you have to do is "execute" the rule using the built in interpreter. Java+Ruby=JRuby is a great example of this.
It's really a fairly long topic to get into here, but if you dive in you might find that you like it. I'm a big believer that the business logic should stay as far away from the code as possible, so DSLs make a great deal of sense to me.
If that's too big an undertaking, then ask yourself whether the rules can be parameterized, as in your example. Maybe you leave the rule hardcoded (for now - never a permanent answer!) but put the variables that rule depends on into the database, with a way for the business person to set those. You should never ever have to go through a code deploy (you do have a whole lifecycle that includes source control checkins and unit testing, right???) just to change a single number or two.
Source(s):
http://en.wikipedia.org/wiki/Domain-specific_language
http://msdn.microsoft.com/en-us/library/bb126235.aspx
Written a bunch myself, from the guts of a natural language search engine to a logical CSV validator.
| Asker's Rating: |
• Thanks for your help everyone, shakespearegeek in particular! You get the best answer because the methodology you describe is close to what my company as a whole is trying to eventually move towards, but tips all around for sharing your experiences.
Permalink | Report
Reply
Other Answers (3)
January 21, 2009 03:35 PM
I think that if you try to make a way to describe them in a database, you're just adding another layer of complexity to the problem. Even if the rules change, if you're the one that will have to change them, the best and easiest way to do that is in source code if you know the language.
Just make sure you do it in a way that is easy to read, use comments and descriptive variable names
Maybe you can put common variables that are susceptible to change in a database and connect it to an easy to use front end.
But when it comes to the actual logic, I think hard coding will save you a lot of headaches.
Update:Ideally you should have the business logic in a separate file or library, that way it's easier to maintain, update etc.Here's an article I've found on The Daily WTF that should be an interesting read: http://thedailywtf.com/Articles/Soft_Coding.aspx
Permalink | Report
Reply
January 21, 2009 04:15 PM
1) DOCUMENTATION IS KEYBeyond the code, the key to solving your problem really comes down to documentation. No matter how you code the solution to this problem, documenting what and why you did it will be very (very) important.
Personally, I use a combination of block diagrams, inline comments that refer to those diagrams, and text to add additional information to the diagrams. This combination has proven to be exceptionally useful and helps everyone (not just programmers) understand the flow of information through a complex system. If you'd like an example of my block diagrams, etc, just ask and I'll whip up a sample in a reply.
Taking the time to compose what feels like a manual at this stage will not only help you get your head around complex rules, but it will allow you to "pass the buck" up to the folks who define the rules. They can approve and add / change rules whenever they would like. I find that leaving this sort of stuff up to the "suits" always frees up development time.
2) CONCEPTUAL CODE
As you know (because your worried about it), simplicity is key. Without completely understanding your problem, I would likely create a unique validation class. Inside of this class, every option and variable would exist. This is similar to the DSL method that Shakespeare mentions but while DSL is common with high level business and project management folks, classes are universally known by all professional programmers. The other benefit of building a class is that it is easy to insert other required scripting or validation functions within it.
3) WRITING IT
If this is a web based application built out of PHP, mySQL and Javascript, here is what I would do: After the user entered data, I would use javascript to check the validation rules. Then on Submit, I would validate the entries again with PHP. Importantly, I would perform one last check after the data had been cleaned (for security) before the data was insert into the database.
This 3 tiered method would ensure that the correct data entered the database. The only way that data could be entered incorrectly would be due to validation rules that are not defined.
I hope that this helps, Darth!
Source(s):
I'm a professionally trained programmer in a few different languages with years of experience.
Permalink | Report
Reply
January 22, 2009 04:01 AM
We have done this quite a few times, which is great because you can change the specific points of the rules without reprogramming. The main thing is that you need to simplify your rules as much as you can.Another thing is don't try to cram all of the rules into one model. You need to look for patterns, maybe you have two or three types of rules and you can use that to design the structures used to store and read them.
Don't worry about adding complexity, because this is work that is going to pay itself after the first 2-3 times that you have to go back and change a date or an amount simply because the customer either changed her mind or there was a typo in the spec documents.
Some examples of rules we were able to implement:
1. Minimum and maximum dollar figures used to select a commission rate.
2. Arbitrary month periods with variable start/end dates.
3. Variable workflows, where answering with a specific value forces events to be called in different order.
Permalink | Report
Reply
Answer this Question
Related Questions
Ask a Question
Buy Mahalo Dollars with Credit Card or PayPal
Top Members
Most Popular Tags
Categories
- Anonymous
-
Arts & Design
-
Beauty & Style
-
Books & Authors
-
Business
-
Cars & Transportation
-
Consumer Electronics
- Coupons Deals
-
Education
-
Entertainment
-
Environment
-
Fitness
-
Food & Drink
- From Email
- From Iphone
- From Twitter
-
Health
-
History
-
Hobbies
-
Home & Garden
-
How Tos
-
Humor
-
Jobs
-
Legal
-
Local
-
Love & Relationships
-
Mahalo Answers Community
-
Money
-
Music
-
News
-
NSFW
-
Parenting
-
Pets
-
Science & Mathematics
-
Services
-
Shopping
-
Social Science
-
Society & Culture
-
Sports
-
Technology & Internet
-
Travel
-
Video Games
Welcome New Members
- samwentcher, November 11, 2009 04:51 AM
- sandii, November 11, 2009 04:34 AM
- chriscortolillo, November 11, 2009 04:24 AM
- sabsmom, November 11, 2009 04:06 AM
- alicia09, November 11, 2009 03:59 AM
Mahalo Dollars are the currency of Mahalo Answers.
Each Mahalo Dollar costs $1.
Once you earn more than 40 Mahalo Dollars, you can request to be paid via PayPal. Each Mahalo Dollar is currently worth $0.75 when paid out via PayPal. Learn More
Having said that, I will leave with the note that all good programmers are lazy, and if you have gone to the effort to separate out your logic and scrubbed it so clean anybody can read or write it, then the next logical step is to step out of the loop completely, and let them. :) You have better things to do than to code business rules.