Business Rules , what are the Tools/Methodologies to categorise/Implement them in .net?
what are the Tools/Methodologies to categorise/Implement business rules in .net? In the book Wisdom of the Gurus in Business Rules chapter by James J. Odell the fact that most of times business rules are actually by product of how a system should behave has been mentioned. My Question is how is one to reformulate the business rules that expressed in natural language to Object Behaviour by implementing them using Events and Methods? For example the rule: Do not take new order from customers that have more than 3 outstanding invoices, following combinations for implementation come to mind : 1.Implement some checking in the AccpetOrder method of Order class 2.Implement some checking in the AddOrder method of Customer class n. Implement some checking in the X method of Y class. A.In the Order.BeforeAcceptNewOrder event do the checking and revoke further processing using the BeforeAcceptNewOrderEventArg B.In the X.BeforeY event do the checking and revoke further processing using the BeforeYEventArg. 4.Some other behavioral modification using Events, so the interaction of objects can change dynamically ( as opposed to hard coding business rules ). There are just too many combinations / degrees of freedom in translating business rules into implementation, but surely by now a more holistic has come to being, anyone knows where or how to find them ? Regards Arjang
RE: Business Rules , what are the Tools/Methodologies to categorise/Implement them in .net?
Surely there must be some sort of canonical form to implementation, otherwise we are not software makers and just duct taping hodge podge together. So there is a canonical form to bridge implementation. That explains why all bridges look the same. No? I studied both Computer Science and Civil Engineering and for Structural Engineering in second year we had to design and build a bridge to support 1 tonne over a 1m span using steel L-section and plate of various sizes. During the design stage one student asked the lecturer what the right answer was. He got a scathing reply that there is no right (canonical) answer in engineering. Rather, there are endless possible solutions, some are better than others, some are not fit for purpose, and all trade off different things. I think software engineering is exactly the same, although with much less history and consequently a less mature body of knowledge. To say software should have a canonical solution like building or bridge engineers is to misunderstand the nature of both software and civil engineering IMO. Regards, Ben -Original Message- From: ausdotnet-boun...@lists.codify.com [mailto:ausdotnet-boun...@lists.codify.com] On Behalf Of Arjang Assadi Sent: Friday, 26 February 2010 9:05 AM To: michaelsli...@gmail.com; ausDotNet Subject: Re: Business Rules , what are the Tools/Methodologies to categorise/Implement them in .net? I wish I could agree with that, but how does what we as software engineers do differs from the building or bridge engineers, surely they don't build bridges or building on what they perceive to be the right way. Surely there must be some sort of canonical form to implementation, otherwise we are not software makers and just duct taping hodge podge together. Every (software) system will gravitate towards maximum entropy and minimum order and the programmer's job is to stablised it by imposing order and decreasing the entropy. Having a structure for defining how a system should be implemented would reduce the number of possible permutation and hence decrease the entropy. I believe a systematic approach to defining and implementation is necessary other wise we are just adding to total sum of junk in the world. Regards Arjang On 26 February 2010 11:21, silky michaelsli...@gmail.com wrote: On Fri, Feb 26, 2010 at 11:07 AM, Arjang Assadi arjang.ass...@gmail.com wrote: what are the Tools/Methodologies to categorise/Implement business rules in .net? Honestly, isn't *every* rule a business rule? Shouldn't you just handle it via, you know, development?! And then test it via unit testing? I don't understand all this timewasting rubbish about spec'ing it out in some language that you then need to test in-and-of-itself and then have that generate it in yet another lower language. You haven't solved anything with that approach anyway. You've just shifted your problem. It's good sometimes, it's bad sometimes, it's not an answer to the underlying issue that to implement Business Rules you need to: 1. Understand them 2. Know how to program them 3. Test them This is our job - this is the purpose of programming. Converting ideas into things, and things into useful things, working things, correct things, and fun things. There are just too many combinations / degrees of freedom in translating business rules into implementation, but surely by now a more holistic has come to being, anyone knows where or how to find them ? Yes - your brain. It is the translation mechanism. Regards Arjang -- silky http://www.programmingbranch.com/ This email is intended for the named recipient only. The information it contains may be confidential or commercially sensitive. If you are not the intended recipient you must not reproduce or distribute any part of this email, disclose its contents to any other party, or take any action in reliance on it. If you have received this email in error, please contact the sender immediately and delete the message from your computer.
Re: Business Rules , what are the Tools/Methodologies to categorise/Implement them in .net?
Silky,
I have to disagree with you...
C#/VB is not the cure to all problems; there are other languages out there!
I have not used a business rules language as such, but I can see real value
in a language where you can show an end user the source code of a set of
business rules like...
TotalClaims = Sum ( ClaimItems )
If TotalClaims ClaimLimit Then ClaimLimitExceeded
You should be able to get your client user to sign off on code like the
above, but try asking them to sign off on...
public bool ValidateClaimLimit( Claim aClaim )
{
decimal lTotalClaim = 0;
foreach ( ClaimItem lItem in aClaim.Items )
{
lTotalClaim += lItem.Value;
}
bool lResult = lTotalClaim _ClaimLimit;
return lResult;
}
If the business rules code can be read and understood by a client user and
compiled into executable code by a business rules engine, then I see real
value for it.
You say...
you need to:
1. Understand them
2. Know how to program them
3. Test them
I would say that you need to:
1.Review the rules
2.Document the rules
3.Understand the rules
4.Program the rules in a machine executable format
5.Test the rules
Your 12 are effectively my 1-4.
All of the steps would greatly helped or effectively eliminated by having
some form of rules engine.
So, I see real value in the question “what are the Tools/Methodologies to
categorise/Implement business rules in .net?”
Interesting to note that a quick search of Google gives 24M results for the
search “dot net business rules engine”.
Regards
Greg Harris
On Fri, Feb 26, 2010 at 11:21 AM, silky michaelsli...@gmail.com wrote:
On Fri, Feb 26, 2010 at 11:07 AM, Arjang Assadi arjang.ass...@gmail.com
wrote:
what are the Tools/Methodologies to categorise/Implement business
rules in .net?
Honestly, isn't *every* rule a business rule?
Shouldn't you just handle it via, you know, development?! And then
test it via unit testing? I don't understand all this timewasting
rubbish about spec'ing it out in some language that you then need to
test in-and-of-itself and then have that generate it in yet another
lower language.
You haven't solved anything with that approach anyway. You've just
shifted your problem. It's good sometimes, it's bad sometimes, it's
not an answer to the underlying issue that to implement Business
Rules you need to:
1. Understand them
2. Know how to program them
3. Test them
This is our job - this is the purpose of programming. Converting ideas
into things, and things into useful things, working things, correct
things, and fun things.
There are just too many combinations / degrees of freedom in
translating business rules into implementation, but surely by now a
more holistic has come to being, anyone knows where or how to find
them ?
Yes - your brain. It is the translation mechanism.
Regards
Arjang
--
silky
http://www.programmingbranch.com/
Re: Business Rules , what are the Tools/Methodologies to categorise/Implement them in .net?
On Fri, Feb 26, 2010 at 12:44 PM, Greg Harris harris.gre...@gmail.com wrote: Silky, I have to disagree with you... Be my guest. C#/VB is not the cure to all problems; there are other languages out there! I never said otherwise. I have not used a business rules language as such, but I can see real value in a language where you can show an end user the source code of a set of business rules like... TotalClaims = Sum ( ClaimItems ) If TotalClaims ClaimLimit Then ClaimLimitExceeded You really show your end users/clients, code? Instead of outlining all of what has been tested (i.e. scenarios)? I don't think showing real people code like the above is particularly useful (or even good). [...] If the business rules code can be read and understood by a client user and compiled into executable code by a business rules engine, then I see real value for it. You say... you need to: 1. Understand them 2. Know how to program them 3. Test them I would say that you need to: 1. Review the rules 2. Document the rules 3. Understand the rules 4. Program the rules in a machine executable format 5. Test the rules Your 12 are effectively my 1-4. All of the steps would greatly helped or effectively eliminated by having some form of rules engine. I disagree. I think you've just moved your code into a new language. So you can program in a new language, so what. Do it or don't do it, what do I care. It's just a different language. Present your information to clients/managers however is best for them. If they understand the statements of a basic programming language, good. Probably, they don't, because it may be hard to convey edge cases, or context, or they will assume various things that aren't true. Whatever works, really. I took issue with the idea there is some magical modelling process you can do to make your code suddenly correct. The process is called programming and it can take place in whatever language is appropriate. Maybe two languages, if it's relevant (one to generate an implementation in other). This is fine, if it works. I don't have any strong opinions about it. So, I see real value in the question “what are the Tools/Methodologies to categorise/Implement business rules in .net?” Interesting to note that a quick search of Google gives 24M results for the search “dot net business rules engine”. I've never based my opinion on what the majority of people do, or even what some sort of subset of people do; I base it only on what I think via the opinions formed from experience and research. Wrong or right, it's the way I operate. So I really don't care that there may be demand for it. Regards Greg Harris -- silky http://www.programmingbranch.com/
Re: Business Rules , what are the Tools/Methodologies to categorise/Implement them in .net?
On Fri, Feb 26, 2010 at 12:05 PM, Arjang Assadi arjang.ass...@gmail.com wrote: I wish I could agree with that, but how does what we as software engineers do differs from the building or bridge engineers, surely they don't build bridges or building on what they perceive to be the right way. Surely there must be some sort of canonical form to implementation, otherwise we are not software makers and just duct taping hodge podge together. Every (software) system will gravitate towards maximum entropy and minimum order and the programmer's job is to stablised it by imposing order and decreasing the entropy. Having a structure for defining how a system should be implemented would reduce the number of possible permutation and hence decrease the entropy. I believe a systematic approach to defining and implementation is necessary other wise we are just adding to total sum of junk in the world. Careful, if there is a systematic way to doing such things, you will soon find yourself replaced with a system :P Regards Arjang -- silky http://www.programmingbranch.com/
