One reason for using a Domain Specific Language is to separate the business rules from the complexities of designing the system. When done correctly, the business rules can be maintained by business users who are the most familiar with the problem space. To a business user a DSL should be no different than a group of phrases that describe the rules for running the business correctly.
A well designed Domain Specific Language will appear as Descriptive And Meaningful Phrases.
In my previous post I described a DSL designed for running a poker room. I defined the syntax of the DSL as:
if the '$5-$10 Limit' list is more than 12 then notify the floor to openIn the example I defined a
bubblemethod that created methods for each member of the list passed to
bubble. Each method that was defined by
bubbletook one value and returned the same exact value. This allowed the DSL to be verbose enough that not every word was required to have meaning. In fact 'the', 'list', 'is', 'than', and 'to' are all bubble methods. Without bubble methods the DSL can be DRYed out to read:
notify floor open if '$5-$10 Limit' more 12However, the meaning of the business rule has been lost at the expense of removing the duplication.
As businesses change, their software requires changes also. By providing a meaningful syntax such as
"if the '$5-$10 Limit' list is more than 12 then notify the floor to open"the software can be altered by poker room managers, casino executives, or anyone well educated on poker room management. However, with every word that is removed the message becomes less descriptive and thus less maintainable.
A sure sign that there is room for improvement is when a DSL requires training to understand. An ideal DSL contains phrases that are descriptive and meaningful enough that they require no explanation at all.