That’s an interesting post. I really think DSLs are different and complementary to the rules universe. A successful DSL should be able to express the ‘intent’ of the user in the ‘lingua franca’ of a given domain. A successful BR platform should allow a user to define decision points and the rules that govern them.

Not every expression of intent requires a decision point in my opinion. In a sense, there is a declarative-imperative relationship here between the two. With rules, you really get to define “What?”. Good DSLs let you express “How?”.

Ideally, a complex domain, like Government Pensions, would have a blend of both. Additionally, this is precisely the premise behind Charles Simonyi’s Intentional Software start-up. http://www.intentsoft.com

I have no affiliation with the company.

I think there is a false dichotomy here.   Business rules when written in an actual business vocabulary, are a sort of “generic DSL.”   That sounds oxymoronic, of course, but it isn’t.   As we both know, there is a large class of policy statements that are straightforward if … then … else statements, and if these statements can be made entirely in the vocabulary of the policy, you’re done.

But I don’t think this means we should dismiss talking about DSLs, or assume that every business rule is best expressed as a “plain” vocabularized production rule.   I’ve seen many cases where creating a specialized rule language (which is certainly a DSL by another name), vastly simplifies expression of policy for the policy manager.   In a project at a major credit processing company, we see business experts writing rules in 10 – 15 lines of a customized rule language or DSL that would take 200 lines of separate production rules.

So: standard, vocabulary based business rules are a DSL, and, they can be made in many cases into even better DSLs if you have a custom language capability at hand.

Philosophically, I am reminded in this of one of my favorite thoughts from A. N. Whitehead: “It is a profoundly erroneous truism, repeated by all copy-books and by eminent people when they are making speeches, that we should cultivate the habit of thinking of what we are doing.   The precise opposite is the case.   Civilization advances by extending the number of operations we can perform without thinking about them.”   Here indeed is the essence of good business rules design: make things so easy to express correctly that people get the right answer without having to think through the parts that should be automatic.   Sometimes (compliance rules in data validation, e.g.) if … then … and vocabulary are enough for that.   Sometimes, a better notation (custom rule language, DSL) can give you big boost in value beyond if … then.