Business Rules, Encapsulation, and Models of the Real World
|In this one-per-month special 'notepad' series, I am taking a quick look at important issues facing practitioners who are seeking to understand and apply the business rule approach for capturing business requirements and developing business systems.|
Real-world objects undeniably have behavior. My dog barks. Why he barks is often a mystery to me. So we can safely assume that my dog 'encapsulates' certain knowledge (internal state?) for his (barking) behavior.
It also very true that my dog's barking can get me into trouble with the city if the neighbors complain about his barking being a nuisance.
Looking at the situation from a modeling perspective, the problem of interest is clearly larger than just my dog and the mechanics of his barking. Certain knowledge is clearly shared by my neighbors and me (and perhaps the city) that is not naturally encapsulated into any single object.
To explore this issue further, let's examine relevant elements of the problem from a business rules perspective.
Fact: Dog barks. (Or dogs can bark.)
Rule: The owner of a dog must be accountable for nuisance barking of that dog.
Rule's Enforcement Level: To be enforced at the discretion of the investigating officer. Note: I might sometimes be willing to take a chance on this -- for example, if I feel there are suspicious people lurking about.
Enforcement Process: Stop dog from barking.
Possible Algorithms for this Enforcement Process (I get to chose):
- Bring dog inside.
- Play with dog outside.
- Occupy dog with bone.
Note: The neighbors don't care which algorithm I use -- they just want results. In fact, because of the wooden fence around the backyard, they can't even tell which algorithm I use.
- This analysis reveals the existence of shared knowledge -- the term, fact, and
rule among the elements above. I believe there is always shared knowledge
associated with any process that involves multiple parties (e.g., my neighbors, the
city, and myself). A complete model of the problem should include direct representation(s)
of such shared knowledge.
- Shared knowledge should not be encapsulated -- that is, held privately.
Indeed, 'private shared' knowledge is basically an oxymoron.
- The algorithms and internal state of the stop-dog-from-barking process can be encapsulated. In fact, from the point of view of the other parties, they should be. All the other parties want or need to know is the following: (a) input - barking dog, and (b) output - silent dog.
Do all real-world objects encapsulate some meaningful algorithm and internal state? Granted, both my dog and I play active roles in the process, and clearly, we are both capable of dynamic behavior and private knowledge. We do encapsulate.
But what about the bone in one of the algorithms given for the stop-dog-from-barking process? A bone has no meaningful behavior of its own that I can discern. Yes, it does play a role in the process, but the important thing is what we can know about it -- i.e., what knowledge properties it has (e.g., is-consumable and is-liked-by-dogs).
A model of real-world things should see these things (objects) as they really are. Many -- perhaps most -- things do not have meaningful behavior of their own. The are inanimate. What's important about them is the following: (a) our shared knowledge about them, and (b) what roles they can play in processes. A bone is simply a bone -- make no … puns about it!
# # #