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.