Is a DSL suitable for you?
Answering this question requires a bit more discussion and work than I can provide on this page. One of the first steps of any project is to investigate exactly this question. But here are some considerations that we would explore together if you are interested. I detail them below.
The most important consideration is this: you should only develop custom tools and languages for that part of your software that is unique to your business, that drives your unique position in the market. It is crucial that your tools are as effective as they can be for this part of your software. Everything else should be treated as commodities, and you should rely on off-the-shelf tools and frameworks as much as possible. To make this concrete: unless you are Amazon or Netflix, then computing infrastructure, deployment tools and databases are not something you want to develop specifically for company. However, if your USP is algorithms for digital therapeutics, then a domain specific language that helps you express this algorithms as effectively as possible is a great investment (see chapter 6 in this paper).
Here are some more thoughts on when a domain is suitable for "domain-expert programming" with DSLs:
A Suitable Domain
Richness and Variety
Is the domain suitably deep, does it have enough intricacies and variety? Is it timeless to some degree, will it still be relevant five years from now? Are there people who are experts in the domain, who have spent half a life understanding it? Is there a rich vocabulary and specific notations? Would non-trivial analyses be helpful to users?Boilerplate and Fanout
Some software platforms require a lot of boilerplate code to use them correctly. In other cases, lots of derived artifacts — such as documentation, design diagrams or coverage reports — are necessary to comply with a particular process. Both cases are excellent opportunities to describe things once, at a suitable level of abstraction, and then automatically generate code and documents.Platform Independence
Another driver for DSLs (and subsequent code generation) is the need to run the same domain logic on different platforms. Either in parallel (e.g., server and phone) or over time (e.g., your systems' functionalities lives longer than the technology of the day), and you don't want to reverse-engineer things over and over again.A Suitable Business Model
A Medium-term Outlook
A DSL is not rocket science, but it is an asset that will pay itself back over time. How long the amortization takes depends primarily on the increase in efficiency you gain from using the DSL vs. the investment for its development. But if your business focuses only on the current quarter then it's hard to make DSLs work.Benefit from Effectiveness
If you are a solution provider and sell time, people or effort, then an increased effectiveness of your development effort might not be terribly useful. If you sell products and want to release on a shorter cycle, or if you develop systems internally and want to accelerate your business agility, a DSL can be a great investment.A Degree of Sameness
Like a framework or a library, a DSL embodies a set of abstractions that you use all the time in your work: if each of your products or projects is in a different domain, it is harder to justify the development of a language for any one domain — and you might also not have the deep experience necessary to build a good one. In contrast, if you develop digital therapeutics apps, satellites or payroll software all the time, then investing into making this more efficient is great!A Suitable Organization
Technical Maturity
Developing a DSL (and using it at the same time) requires a certain maturity of your software development process: you'll have to manage the requirements for the language, develop it incrementally, ensure quality and regularly release it to your users. If you and your teams struggle with build automation or unit testing, developing a DSL might be a step too far. On the other hand, if you have done platform- or framework-based development in the past, a DSL is a logical next step.Willingness and Ability to Change
A DSL moves the "threshold of formalization" back in the development process, from software developers to domain experts. This is probably a significant change in your process. It requires people to change, to learn new skills and to go through some a period of reduced productivity as they learn the new approach. The technical developers have to learn how to develop languages and runtimes. Both skills that are not too widespread. Everybody needs to be on board to harvest the benefits of the approach.
... or continue Reading:
How to adopt a DSL?