Re: Where do business rules belong... OCP and SPs

From: Rod Davison (critsys_at_rogers.remove.com)
Date: 01/22/04 

Date: Thu, 22 Jan 2004 04:29:20 GMT

Perhaps we should take a step back and ask "What is a business rule?" it
is one of those terms that tends to get thrown around without really
taking the time to think about it yet alone define it.

For example, suppose that we are designing an application that allows a
loans officer at a bank to enter some client data, then generate a
quantitative risk factor that is then, in turn, used to decide whether or
not the client should be approved for the loan.

If we think about this process we see that there are a number of different
kinds of "business rules" operating.

1. Data Well Formedness: The form must be completely filled out. The
phone number field should look like one of (ddd) ddd-dddd or ddd-ddd-dddd
and so on. Email addresses should have a "@" in them. We do not process
the form until all of the data is complete and in the right "form".

2. Generic Data Constraints: These are general rules about the values of
the data that should be universally true (or close to universally). For
example, the client's date of birth cannot be later than today's date. The
applicant city and zip code should match (Dallas is not in zip code
10045).

3. Specific Data Constraints: Unlike generic data constraints, these rules
relate the validity of the data values to the specific business domain.
For example, the applicant name and co-signer's name should be different.
The applicant must be over 18 years old.

4. Data model rules: These are rules that describe the structural
relationships and constraints of the data/objects. For example, each
applicant is assigned to a loans officer and a loans officer manages a
number of applicants. If a loans officer is terminated, then all
applicants assigned to that officer are reassigned to that officer's
manager.

5. Business Logic Rules : These can be thought of as the algorithms that
are deterministically invariant (i.e. No matter how often or when we
execute the rules, the same inputs always produce the same result). In
this case it might be the calculation of the risk factor for the loan.

6. Inferencing Logic Rules: These are non-deterministic business rules,
which means that executing the same rules with the same inputs may produce
different results depending on when they are executed. For example, a
risk factor of 5 might be enough to get approved on Monday, but not on
Thursday when the bank discovers that it has a higher than expected rate
of bad loans. Normally people do this sort of adjudication.

7. Process rules: These are business meta-rules that define how the
business rules are to be applied, in what order and how the business
process ought to run.

Given all these different kinds of rules, it seems natural to ask where
they go. A simple starting point might be to answer "closest to the
object that uses them". So should the data well formedness rules go in
the business tier or perhaps in the presentation tier? I would suggest
that it is more natural to put them in the presentation tier ("more
natural" does not mean "must be"). Similarly, rules about about
data model structure more naturally would go in the data tier -- which
with your feeling that some of your rule should be stored procedures.

Of course
you also have to balance that with what the tools you are using allow you
to do effectively and efficiently. SO data bases should have pretty good
tools for supporting data structure rules, etc.

Of course, as we get into the whole area of the need to modify rules as
the business requirements change (like we need to support European phone
numbers as well as North American) we want to start looking at decoupling
the rules from the application components. But that is a whole other
issue as well.

On Wed, 21 Jan 2004 16:29:10 -0800, Yaron Bental wrote:

> Robert C. Martin <unclebob@objectmentor.com> wrote in message
> news:<unnr00dvr86nq8snkbj9gvu5dt79g4gij2@4ax.com>...
>> On 18 Jan 2004 20:38:36 -0800, bentalcy@yahoo.com (Yaron Bental) wrote:
>>
>> >Hi
>> >
>> >Being an OO follower I believe, and I know a few other do too,
>> >business rules belong in the business tier, we all know the reasons.
>> >With that habit in mind and in practice I set some time this week to
>> >improve performance on a very slow page in one of the apps my team is
>> >responsible for. I knew I have to touch a set of stored procedures and
>> >in my mind I thought I wanted to move all the business rules captured
>> >in the stored procedures back to where I think they belong.
>> >
>> >No meter how hard I tried I could not move those rules into the middle
>> >tier, performance would just degrade. Some of the stored procedures
>> >filter (using some very complex business rules) through hundreds of
>> >thousands of records. Simply moving this data into some classes and
>> >filtering/calculating it there, just doesn't make sense, from
>> >performance point of view.
>>
>> The back end server can do some things much much faster than the middle
>> tier. That's just the nature of the beast. That means that there will
>> be some things that you must delegate to the back end. However, that
>> doesn't necessarily mean that you have to move too many business rules
>> down there.
>>
>> First, try to limit the stored procedures to only those things that are
>> slow. Then see if you can abstract any reference to business rules
>> away from them, so that they become pure mechanism. The more you can
>> view them as a toolkit of finely grained general purpose tools, the
>> better.
>>
>> Clearly there will be some things that don't fit this mold, and you'll
>> just have to put the rules down in the stored procedures. So be it.
>
> Thanks very much for your input! Would you agree then, that one cannot
> always conform to the OCP. IOW some business rules should live in the
> sps (although we don't like it) at some point down the road i might need
> to change existing code even just to extend behavior? 

-- 
.................................................
The only substitute for good manners is fast reflexes.
Rod Davison -  Critical Knowledge Systems Inc.

Relevant Pages