Components and Business Rules: Do They Connect?

by Ronald G. Ross

This column originally appeared in the Jan./Feb. 1998 issue of the Data Base Newsletter.

If you just want to know my answer, here it is: I don't think so. If you want to why, read on.

I recently spoke at DCI's Database and Client/Server World in Chicago, which was all abuzz about components. Clearly, components are The Newest Thing in software development.

I must say I did not go in really expecting a clear answer. After all, components are largely a software engineering concept, and by and large, that community is not plugged into the IS view of business rules (i.e., terms, facts, and rules). I did, however, expect at least a common definition or understanding of the concept of components. Maybe that was naive.

What I essentially found was a flea market of ideas -- lots and lots of variety, but not too many real bargains even at flea market prices. And alas, despite universal lip service to "the business," I find that the programming mentality is still very much alive and well in our industry today. These are some of the same folks who brought us objects as the ultimate solution, and before that, structured techniques, and before that, modular programming. Actually, that last one was a very good idea. In some ways, components simply bring us full circle.

Be that as it may, let's not waste time on the muddle. Instead, let me focus on the best of what I heard, which was offered by Grady Booch of Rational Software (and UML fame). For my money, he gave the clearest vision of components, and developed the related concepts quite well.

But what he said about business rules did not compute for me. Here's what he said: "If you componentize a business rule, that becomes a replacement part." That is a nice sentiment -- yes, business rules should be re-usable in that sense -- but what does "componentize" mean? Let's look a little deeper.

The definition he offered for component was as follows. "A component is a non-trivial, nearly independent, and replaceable part of a system that fulfills a clear function and that can be used in assembling a well-defined architecture." No problem there.

But there was more. He went on, "A component conforms to and provides the physical realization of a set of interfaces that specify some logical abstraction." Let's leave aside the part about "physical realization." (At one point, he described a component per se as a "bag of bits." There are reasons for that.) Let's also leave aside the part about "logical abstraction." (There is nothing wrong with that.) The important point is "set of interfaces," which he said should be "well-defined."

Consider the following typical business rule, stated declaratively (as all business rules should be): A group must not include any non-union members if it includes any union members, and vice versa. Before I get to the issue of interfaces, let me digress and ask a different question. Is this sample rule big enough to be a component? (Business rules must be atomic so they can be independently changeable.) Booch didn't talk much about the size of components, except to say that they are generally larger than objects, but smaller than whole applications. I sense a probable disconnect right there.

What about "interfaces"? If the business rule is a component, then it must have a set of interfaces. But what would it be? Unless the interface is the state of persistent data (i.e., the database), I am at a loss. A rule should simply wake up -- i.e., fire based on appropriate events and conditions. Nothing needs to ask it to, so why would it need an interface? I may be missing something, but the ideas just don't connect.

standard citation for this article:

Ronald G. Ross, "Components and Business Rules: Do They Connect?" Data Base Newsletter, Vol. 26, No. 1 (Jan./Feb. 1998), URL: http://www.BRCommunity.com/a1998/a377.html