Declarative Programming (Business Rules)

Complex business logic is the main issue that keeps developers awake at night. As the application evolves, it’s very hard to write and maintain this code.

The problem behind this is that this cannot be easily solved using standard imperative programming style (imperative programs are a sequence of commands for the computer to perform, e.g. languages like Java, C++ …). The most straightforward approach is to use declarative programming (languages that describe a problem rather than defining a solution, e.g. Prolog, SQL, XSLT) i.e. you are not saying “how” the computer should do it, but “what” it should do.

Since we are using an imperative programming languages one common way to avail of benefits that declarative programming brings is to use a Rule Engine or Expert System. Wikipedia defines the use of a rule engine in IT as follows:

“For any application the business rules change more frequently then the rest of the application code. Rule Engine or Inference Engines are the pluggable software components that separate the business rules from the application code. This allows the business users to modify the rules frequently without the need of IT intervention and hence allowing the applications to be more adaptable with the dynamic rules.”

Simple example
An imperative method for ensuring you have your sunglasses if the sun is shining would be:

  1. Step outside and determine if it the sun is shining.
  2. If the sun is shining, then get sunglasses from shelf

The above could also be represented by two declarative rules:

If it the sun is shining
Then you need you’re sunglasses

If you need your sunglasses
Then get them from the shelf

Given declarative rules, the knowledge that it is sunny could produce two
courses of action:

  1. You already have your sunglasses, perhaps because you’re cool, in
    which case, you’re ready.
  2. You don’t have your sunglasses, so you go get them from the shelf.

This allows you to use the knowledge you have and respond to that knowledge in the most appropriate way. You could, for example, already know it is sunny and simply get your sunglasses from the shelf. If you thought the sun was going to shine you could add another rule to the ones above:

If the sun might shine later, and
If you’ll be away from the house
Then you need your sunglasses

At this point, you only need to get your sunglasses if you know you don’t already have then, and either the sun is shining, or that it might shine later while you’re away from the house. If you were to write that all out in procedural code, it’d quickly get tangled and complex.

Some of the advantages of the declarative method:

  • Simpler (i.e. cheaper) maintenance
  • Reduced development time for complex business logic
  • Higher performance, due to the algorithm optimization (business logic doesn’t run more times than necessary)

It might be surprising to discover that rule engines receive a lot of attention in the insurance claims, tax preparation, and medical industries. Sometimes, just having a system that can sift through reams of data and highlight the extreme cases can be of tremendous help.

Jess – Java Expert System Shell
Jess is the JSR-94 reference implementation. The syntax for the rules definition in Jess is based on LISP. The cost of learning a new language to define rules was considered too high to justify the uses of Jess for projects here in DSI. Coupled with that, Jess requires a license for commercial use. However, there is an interesting article on when to use a rule engine. I would disagree with the conclusions on ROI we saw payback almost immediately. This was mainly due to changing requirements.


“Drools is a Rules Engine implementation based on Charles Forgy’s Rete algorithm tailored for the Java language.”

Here at DSI we are using Drools. Currently rules can be written in Java, Python and Groovy. It supports the JSR-94 specification. This is not as important as it would seem as the specification only defines the interaction with a rule engine. So even though we can switch between rule engines by changing Spring configuration files, in pratice this would require a rewrite of the rules themselves to comply with the new engines rule syntax.

Drools adds another convenience to writing rules called Decision tables.

“Decision tables are a useful way to represent conditional logic in a compact format. This format is also readily readable and editable by non technical users (such as business analysts). Drools decision tables can utilise a spreadsheet (such as Excel) as the means to capture decision logic, in a user friendly way.”

We then take the spreadsheet and use a converter that converts these rules into drools-rules representation.

In conclusion
Declarative programming, for many, is a completely alien paradigm which should warrant a careful and thoughtful study before attempting to write “live” code. In some respects, Jess’s use of a LISP like syntax help people make that paradigm shift. Failing to do so can result in inefficient rules and seemingly unpredictable results. Debugging can be extremely difficult without an understanding of how the underlying system is working. Rule engines have many advantages, but on the other side they can be dangerous if you don’t know exactly what’s going on.

– Noel Keating
– Michal Bali

  1. #1 by Hosting on March 19, 2007 - 2:28 pm

    Is there any rule engine for c ?

  2. #2 by droolsbeginner on January 30, 2008 - 4:57 am

    The Drools decision tables seem pretty cool, just wanted to know how exactly you integrate it with the business components data ? ; i assumed the rules are compiled once and cached/stored – is it stored in database ; application cache ; any other mechanism?..i wanted to know some real world solutions for doing that. Also, how do the rule updates flow from the business user to production ?

  3. #3 by Val on August 17, 2011 - 6:10 pm

    This is a great description of the advantage of declarative vs. procedural (imperative) programming. For transactional business logic, you can now avoid Anemic Domain Objects with Declarative Transaction Logic (see, which works in conjunction with Rete Engines (see

  4. #4 by Matthew C. Kriner on September 14, 2011 - 4:39 am

    Another thoughtful posting, Good material. I wanted to say I just looked over more topics you made and I you’ve got some nice content. I’ll be back.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: