I saw this piece on DSL and MDE, necessary assets for Model-Driven approaches and it made me think about DSLs. First, here’s the definition of a DSL from the article
DSL is a programming language or executable specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain.
I notice some pieces of advice about DSLs in this article that make me think business rules would work better. First he suggests that you:
Implement DSLs in a way that they are directly executable on a specific platform. For making them executable on another platform the generator or interpreter needs to be rewritten
Well a business rules management system handles this for you. In fact several commercial BRMS products allow you to execute as COBOL, Java or .Net from the same rules. Next he says:
Make DSLs extensible by existing GPLs [General Purpose Languages], programmers can formulate the necessary additions in a language they know.
Most BRMS products do this inherently, allowing business rules to access functions written in C# or Java or whatever. He goes to quote someone who:
emphasizes that for tackling the complexity of software development a language is needed understandable by both developers and domain experts.
This, of course, is a key value of using a business rules approach and a BRMS. Now thinking about DSLs and how often a business rules approach and a BRMS could (and should) be used instead made me remember an article on Business Natural Languages (a better name IMHO for DSLs) I saw some time ago in which Jay Fields said:
The more business specific logic you can abstract out of an application the less programmer involvement you will need to alter the business logic.
Then, more recently Jay had a post on Designing a Domain Specific Language in which he talked about building a system that allowed the
director of finance for the client bank to edit, test, and deploy the business rules of the system without any assistance from IT
Hmm. So far this all sounds like the kind of thing for which business rules are ideal. Not only are they declarative and clear for business users, they typically act against an object model in a way that allows more business-friendly names to be used – essentially hiding the objects and their complexity. If you like you can even use various web-based editors (with most commercial products) that hide even the structure of the rules themselves, allowing a point-and-click interface. Taking a business rules management system and building a domain-specific environment on top seems to me much more efficient than creating a whole DSL from scratch.
DSLs come up a lot, especially in the context of model driven engineering or development or architecture (MDD/MDE/MDA). Personally I think business rules work better and do so without you having to write a bunch more code. Models and business rules, perfect together.
Comments on this entry are closed.
James,
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.
James,
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.