Udi Dahan has this post on Domain Driven Design (DDD) that I found interesting.I would say that no discussion on DDD would be complete without a mention of Business Rules. After all, it is Business Rules that adds most of the complexity that surrounds building Business Applications.

It is business rules that change most often and which come, at least as the programmers see it, come with so much different varieties that it is difficult to capture, model and implement quickly and in a bug free fashion.

Business Rules apply in all the different layers of an application. Let me take an example to illustrate this.

Imagine a Online Agent Broking System for Loan Products. Now, to qualify applicants, a whole bunch of questions would need to be asked of them. The set of questions depend on the answers to the previous ones, and the answers to the current ones determine the next set. Modeling this in code is certainly possible, but modeling the Q & A sequence as a Rule driven process will make it more visible and enable faster changes and simplify bug fixing.

In the same application, a whole lot of eligibility rules would apply for qualifying an applicant. Add to this, the adjustment & settlement rules for broker commissions. Additionally, the ratesheets are sensitive to the capital market, and typically change 3-4 times a day.

The Domain Model, explained in Martin Fowler’s Patterns of Enterprise Application Architecture is the heart of a DDD. Business Rules typically apply on the Domain Model. But, any Enterprise Architecture effort must have a clear vision as to how the Business can be involved more and more in IT Systems Development & operations. And this means a clear Rules architecture must be envisioned, and no rules architecture will be complete without a BRMS.

Business Rules are found in many forms and in many places in an application. In the UI layer, it is not uncommon to see Business Rules embedded in javascript. Stored Procedures are another place where you would find Rules. And of course, rules will be found scattered across the application code base including the “Business Logic Layer”.

I will admit that in some applications, using a BRMS might be an overkill or might not be an immediate requirement. But, if your enterprise requires that

1. Business & IT MUST collaborate to enable concurrent engineering
2. Business Users should be able to make controlled changes to the IT System by themselves, like for example changing the Pricing Rules by themselves.
3. It must be possible to change the system quickly at short notice
4. The Business Policies enforced by the application MUST be visible

then, you would most certainly need a BRMS.

If a conscious decision & planning is not made about how the system will handle its Business Rules, it will only only lead to a rigid frigid system that is difficult to change and is hard to maintain.