That's why I've long though the term programmer/analyst is the most
accurate description of what we do. This question is actually a little
larger than it looks at first, but we can start with the fundamentals
that we always use: identify the conditional processing which in turn
depends on how the condition is specified and how it affects the processing.
In this case, the condition is pretty simple: took care of Mr. Kelly's
car during the Depression. That's a function that you call that returns
True or False. The devil is in the details of course. Could this apply
to someone other than Mr. Kelly? Could there be a different date
range? The database implementation could be as simple as a flag on the
employee file, and the function could take an employee number and return
an indicator. Or you could have to specify an owner ID and date range,
have a vehicle master with owner ID, and a vehicle care log, and bounce
the employee number against that log. But at the end of the day, you
start with an employee and get a yes/no flag.
The processing is a little trickier as well. When is this rule
applied? And that in turn hinges on how the rate is stored and
accessed. Is there an employee maintenance function that sets the rate
in the employee file? Or do you always retrieve the rate dynamically
from a rate file based on the employee classification?
If the rate is stored by employee it's both simpler and broader in
scope. When you maintain the employee, you update the rate. That's
where you apply the business rule. Assuming that the rate is updated in
the employee master based on the union position, then changing the
position should change the rate. The simplest plan would probably be to
have two fields: a rate and an adjustment. When you update the rate,
also check the flag and if the flag is set, put .05 into the adjustment
field. Then when you retrieve the rate, retrieve the sum of those two
fields. So the business logic goes into the update/read of the employee
record.
If instead you retrieve the rate dynamically from a rate file, you put
similar logic into that function: use the employee to get the union
rate, then use the employee to get the adjustment, and add the two. So
in this case, the logic goes into the rate master file.
So, at the end of the day, the business logic is attached to the file
whose data point is changed based on the condition. I know tha'ts
pretty simplistic, but a good architectural approach is nearly always
simple. That's not to say it's always easy; simple and easy aren't
necessarily synonyms. But the same way that I know my code is getting
better when I start removing lines, I know my design is getting better
when I start removing complexity.
On 11/8/2018 8:19 PM, Booth Martin wrote:
My first eye-opening experience with business rules was the rule
"Anyone who took care of Mr Kelly's car during the depression gets a
nickle an hour above the union rate." That happened to be one guy.
But there had to be a rule. How does one put that rule in the database?
On 11/8/2018 7:35 PM, Jim Oberholtzer wrote:
That's what a properly designed database does, enforce business rules
with constraints and relational integrity built in. It's not that
hard to build.
Jim Oberholtzer
Agile Technology Architects
midrange.com
