Business Flow And Business Rules

It has been frequently argued that your design should attempt to separate the business rules from the business flow. To clarify what I mean by this, consider these definitions:

A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure, or to control or influence the behavior of the business.

The business process (or business flow) is any collection of activities that when combined accomplish a given business objective. For example, processing a credit card number, hiring a new employee, and submitting a patent are all examples of business processes.

Isolating the rules from the flow allows separation of concerns among your developers, and separates elements which may have very different rates of change.

Two questions:

1. Is this a design practice that you have seen/have used/believe is important?

2. Are there underlying design patterns already published in the industry literature that give guidance on how best to accomplish this goal? -- BillBarnett

I seem to be especially talented at creating wiki pages that go echoing off into the void of vast silences. This one is an especially fine example. I assume that is because it is so brilliant and profound that no further comments are necessary. It certainly couldn't be that it is so flawed, hopeless, and incomprehensible that no-one knows where to begin. :)

Anyway, here is the content in the CommonChannelArchitecture on this subject. Do you think this holds water? Is it a valuable recommendation to make to developers?

5.2.1.5 Separate Business Rules from Business Process Flow

Business rule: A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business.

Business process: The business process is a collection of activities that when combined with business rules accomplish a given business objective. For example, processing a credit card number, hiring a new employee and submitting a patent are all examples of business processes.

The business process represents the steps that are required to fulfill a user’s request. For complex applications, or for services that may be used across multiple channels, these steps should be encoded in a TransactionScript. The business rules are bits of logic that define or constrain some Aspect of the business, and control the behavior of business entities. For complex applications, or for services that may be used across multiple channels, these rules should be built into a DomainModel.

While it is possible to implement the process and the rules together in the same classes (whether in a TransactionScript or DomainModel) there is significant benefit in separating them out. The rules and the flow may well need to change independently of one another depending on changes in business requirements. Isolating the flow in its own transaction scripts increases the likelihood that the process can be reused across multiple channels.

For highly complex or dynamic applications, consider the use of an external business rules engine. The primary goal of such an engine is to allow easy maintenance of the rules, which are likely to change faster than the flow. This is especially critical if the business rules typically change more quickly than the release cycle or if business analysts or other end users need to be able to maintain their own business rules.