The project I'm currently working on is based on a rather narrow domain, but with a high density of business rules that comes along. Currently we are writing the rules directly in code, but there have been some pressure about using an in house created XML based rule engine. As the rule base becomes bigger and bigger the more the pressure.
As I see it there are two reasons for using a rule engine:
- Separate the rules from the code so it can be edited without recompiling the application.
- Let the rules be edited by a domain expert.
Does an XML based rule engine support this? Sure, a rule engine certainly separates the rules from the code and makes it editable. However, I don't really see how rules in XML are much better than rules written in code. Rules in XML can certainly become as complex syntactically as code and I would argue that as the rules get more complex, rules written in code actually get more easy to read and understand. So at my point of view a rule engine doesn't provide a domain expert much more support in editing rules than plain code.
Now comes the real pain with a rule engine; Testing. As the rules are written in XML it becomes real hard testing them incorporating your domain objects. Sure, the XML is often used to generate code, but I don't see how this improves the testability much. The generated code will normally be complex and hard to use as the XML and code generator tries to capture and provide functionality for general purpose problems and scenarios in non specific domains. Refactoring the code won't update the XML and suddenly you find yourself in a maintainability hell. This is why I would rather have my rules in code.
Now the problem with writing rules in code isn't that it is impossible to separate the rules from the rest code. Writing rules in code suffers in the same matter as rules written in XML in that it is extremely hard for a non technical domain expert to read, edit and verify rules. Lets not forget create new rules. I can understand those who argue that rules in XML are more maintainable for a non technical than rules in code, and the fact that there are some stakeholders driven against a XML based rule engine really got me thinking. As I most certainly want to keep my business rules in code for testability and maintainability I started thinking about an alternative way that could let us keep the rules in code and at the same time make them easy to edit, which in turn would satisfy all parties.
A couple of days ago, on my way to work, I was talking to a colleague who had attended a meeting at the
Norwegian .Net User Group (NNUG) where Anders Norås, a former employee at my company held at talk about fluent interfaces and domain specific languages. I immediately associated this concept with my rules problem and started digging around on the Internet. In my search I found at great
article by Anders Norås where he shows an example of an DSL implementation. I would also recommend an
article by Martin Fowler where he discusses the pros and cons of internal and external DSLs.
Although external DSLs can be evaluated at runtime, which has made XML so popular, and the fact that internal DSLs are limited by the syntax of the language of choice, I would still go for an internal DSL. I don't have to learn a new language and I can take advantage of my existing skills. The idea of fluent interfaces seems very interesting. Writing a fluent interface would mean that the domain expert editing the rules could use IDEs and even get intellisense while he/she is typing the rules. Writing the rules in a language like Boo, which runs on the .Net CRL could even let the rules be evaluated runtime. However, I don't see this as an requirement for my problem. Writing a fluent interface in C# would probably satisfy all my needs. Extension methods would most certainly become handy. Still, I'm a little bit concerned about the effort and cost of creating such a DSL.
Hopefully I soon will find the time to implement a little prototype and write a part 2 of this post. I'll keep you posted!
