Where do I store user-defined business rules?

Question

Let's say I have an application that works around departments and employees. Each department has a set of rules that defines which employee is assigned to each department. For instance the system will auto assign the employee to a specific department based on some properties like number of years experience or spoken languages. The tricky part is that those rules are not predefined which means I want the application user to be able to create, delete and modify those rules which means I can't put them in the source code.

How can I do this?

Answer 1

I am sure you have already seen and maybe used such functionality: every decent email client allows a user to define custom filter rules by picking some rule templates, add some conditions and parameters and then making the rules to be executed automatically whenever a new email arrives. So this is actually one posible way (of many) how to implement such a system.

So yes, there is nothing special in having a system with custom rules and logic in it. However, there is a wide range of options and degrees of freedom in this, starting from some simple, parametrized rules from which a user can choose up to a full-blown inbuilt interpreter, with a standard or domain specific programming language for implementing rules, maybe based on some generic rule engine.

The degrees of freedom typically correlate to the development effort as well as to the steepness of the learning curve for the users. So there is no one-size-fits-all solution to this, you need to analyse the amount of flexibility your users need, and "more flexible" is not necessarily better, because it often means "harder to learn". If your users want some flexibility for the business logic, find out how much flexibility they really need, and how much effort they are willing to invest in learning how to define complex rules and logic by themselves.

Answer 2

There's going to inevitably be a compromise with this. If you want to offer the user unlimited flexibility to define complex rules on the fly, then what you're effectively going to have to do is create a domain-specific programming language within your application, which will require you to write something that can then parse this. This is not a small job.

However, it may be that this degree of control is excessive. Your users may be content with the capability to:

1. Define attributes (eg HAS_5_YEARS_EXPERIENCE or SPEAKS_SPANISH or IS_CONVICTED_FELON)
2. Assign any number of these attributes to each employee
3. Specify custom rules for each department (eg REQUIRES: SPEAKS_SPANISH or FORBIDDEN: IS_CONVICTED_FELON)

This is a much simpler undertaking.

Answer 3

I would use a rules engine like Drools (Java). Rule engines basically serve two purposes. One: they execute the rules that they have stored (ie determining which departments an employee belongs to). Tqo: they provide a way to modify the rules at runtime. Rule engines are dynamic by definition. This seems like it fits your scenario perfectly!

Answer 4

You can store your rules in OWL + RDF, a semantic web language standard from the W3C. OWL can represent description logic (see this presentation by Ian Horrocks, and "A semantic web primer" by Grigoris Antoniou, Paul Groth, Frank van Harmelen, and Rinke Hoekstra. It allows you to define an ontology about employees, departments, and job qualifications. And to reason within this ontology. For example it allows you to define properties and the meaning of these properties, to define the requirements of various departments, store the employees qualifications.

With some knowledge of knowledge representation you can change and add properties, change rules for departments, etc.

Next you can use existing OWL reasoners (such as Apache Jena, OpenLink Virtuoso, AllegroGraph RDF store, and Pellet)

Using the reasoner, the ontology you defined, and your database of employees and departments you can find the class of employees who satisfy all required properties to work for department x.

Within the semantic web family of tools there exist OWL reasoners, RDF tripple stores (OWL is often stored as RDF), and knowledge base editors.

Answer 5

Using a rules engine like Drools was already mentioned.

Leaving a large part of the configuration to the end users has a typical drawback compared with programming maintenance:

• Changes have an immediate effect on the running production system;
• Versioning is absent;
• Design is ad-hoc;
• Documentation is absent;
• An end-user is not accustomed to the "logic" of a software system.

Hence sufficient and extra careful development is required.

Do a detailed design, with detailed stories: final user interfaces.

Only after having technical requirements, a technical conception, look for the correct tool(s). So the development times are distributed proportional to the work load parts.

A warning: do not store complex data (hundreds of graph nodes) in several database tables, when that data is like a document; better store such data as XML in one single table (JAXB). It is better if one can step from graph to graph, instead of having all distributed - even with JPA.

Another note: such software should typically ony assist in planning, not necessarily be prescriptive. The client often only wants to optimize, do things fast and unbiased. This means that manual exceptions probably should be dealt with and be documentable.