The idea of domain-specific languages is to allow non-developer domain experts to contribute directly to the software development process with “executable specifications” that are much more useful than prose user stories or requirements documents. And from a software architect’s perspective, DSLs allow the complete separation of the business logic from the implementation technology, thereby avoiding the trap of legacy systems.
In contrast to popular belief, the approach works in practice, as an article I recently wrote on InfoQ shows through a collection of real-world stories that each illustrates how a company benefitted from the approach. The examples come from the domains of systems engineering, healthcare as well as more classical business domains such as finance, insurance and payroll. Each language is different, but the idea, the infrastructure and the language tooling are the same. The article also demonstrates that the automation of software development through code generation is an important benefit of DSLs. But there are others, including analyses, optimization, and, importantly, the much more meaningful inclusion of non-developer stakeholders into the process of software creation.