In recent months there has been a great deal of debate about the value and application of Domain Specific Languages. Andy James, Chief Technology Officer, Solidsoft, examines what they mean in real English, and how they can be applied to improve delivery productivity.
When it comes to Domain Specific Languages (DSLs), the web is awash with references, articles and more than a few blogs. In general, they agree about the value of DSLs, but are light on describing how they should really be applied. In effect, they all seem to be preaching to the converted.
What is a Domain Specific Language?
First of all, for those less than familiar with DSLs, a brief explanation. The basic idea of a DSL is a computer language that's targeted to a particular kind of problem, rather than a general purpose language that's aimed at any kind of software problem. Domain specific languages have been talked about and used for almost as long as computing has been done.
Now we all know that General Purpose Languages (GPLs) are a good thing, but Domain-Specific Languages (DSLs) can be better. Why? Well, they provide a:
natural vocabulary for concepts that are fundamental to the problem domain.
faster way to write common concepts.
Languages are written for a purpose, for an audience. This is true for Visual Basic, C#, C and even Java, as well as English (in all its forms), French and Latin. Therefore, we should ask ourselves - can we really expect them to apply to all purposes?
The problem is that explanation is a domain-specific, task-specific, user-specific inference. This means that high-level descriptions that are crystal clear to you, can be opaque to me. So, a DSL sits above a GPL. It provides a layer of extraction, in understandable terms, which hides the complexity of the ‘lower level’ GPL.
What is a domain?
Now - what do we really mean by the domain? Almost all the examples out there talk about DSLs with reference to utilities, for things like printing and file handling. But this is only one way of looking at domains. What they are ineffectively saying is 'the domain is the problem area to which the language is being applied'.
But there are other ways of looking at the problem domain, and that is from the point of view of the business. Let’s take an example.
In the Insurance sector, companies that provide income protection policies need to follow a number of processes. For the people who work for the company, this is a domain they are familiar with.
They also understand the actions, activities or events (call them what you will) that are performed in this context. They create them, read them, update them, cancel them, handle claims made against them etc. Below this can sit whatever language implementation is necessary for the system and application activities to occur at the right time, in the right way etc.
So when it comes to Domain, we can think of it as a Context.
What is specific?
Now, we move on to the next term which is Specific. When it comes to the language, the general view is that the more specific it is, the easier it is to understand and apply. This is true, so long as the scope is sufficient to cover all the eventualities that need to be addressed.
In the earlier example a DSL that covers the policy administration needs of an Income Protection provider is of limited value generally, but highly effective within the domain. Because of this most companies would need to use a number of DSLs to meet their systems needs. This puts all companies in one of the following positions:
No use of DSLs at all
Using a combination of a DSL and GPLs
Using multiple DSLs and GPLs
Only using DSLs
In reality, number 4 is highly unlikely to ever happen. Most companies start with number 1, progress to 2 and finally reach 3. The reasons for this are the overheads of maintaining a DSL. To create, manage and update a DSL is a considerable undertaking, and needs to be justifiable in terms of the long term benefits to the organisation. Generally speaking, it will make sense for companies to follow the 80:20 rule. By creating or using a DSL to cover 20% of their needs (ideally ‘covering’ the greatest systems complexity) companies will get 80% of the total potential benefit of DSLs.
Over the next few years the use of DSLs is likely to grow. Much of this growth will come from horizontal DSLs, such as those that handle workflow, business rules etc. The rest will result from the layering of industry specific languages over constructs relating to patterns, component libraries and the like.
In summary, languages need to be specific to their application and understandable by those that must apply them. They need to be specific enough to address the domain problems fully, yet general enough to cover the entire spectrum of domain needs, each of which, in most cases, will require a combination of actions, events and activities.