We have discussed six fundamental questions you should answer when building a DSL.
We have discussed the first two questions. Today it is time to answer the third one: which advantages can a DSL provide in your case?
There are several, but these are the three core ones:
- Reduced development cost: this one is simple; by adopting a DSL, you will significantly reduce the communication costs from domain experts, developers, requirement engineers, and analysts. It makes it possible for domain experts and analysts to write themselves a significant part of the business logic, using tools that capture many conceptual errors immediately instead of finding them after the application has been developed. In our experience, this can reduce development times by 5-20 times and costs by almost that amount. Still, building the DSL will have a cost, so we would work with you to understand if we can expect a positive ROI from this investment
- Reduced errors: the DSL is supported by editors and tools to validate it. Given the DSL is high-level, there are a whole set of errors which are impossible to do (no null pointer exceptions, for example), and the error-checking functionalities capture a vast number of other errors. It is essential to understand that in a DSL, we can capture domain-related errors, things that your typical compiler could never catch. The fundamental difference is that a DSL understand the semantics of your domain, while standard languages such as Java or C# do not
- Time to market: what we have seen with industrial applications of DSLs is that, because of the shorter feedback loop, iterations are way shorter, and the product can be improved at a significantly faster pace, leading to releasing it much more quickly than with traditional techniques. This is valid under the assumption that the DSL will be used to build several products and applications. This is something we would check with you, as part of the assessment
Which of these advantages is more relevant to you?
Now, a bit of experience is required to figure out the exact way these advantages are relevant to you and how they can be used in your case. We are analyzing our past experiences to see which factors contributed more to getting these benefits.
This is the kind of question on which we reflect with our clients when considering building a DSL.
As we said previously, we have developed a methodology to assess when a DSL makes sense, if you want to discover more you can read our guide to DSLs, The complete guide to (external) Domain Specific Languages, or discover good books on best DSLs practices.
