Perhaps you have heard of the term “domain-specific Language” (DSL) or “domain-specific Tool” in the software technology area. What exactly does this “domain-specific” mean and how does it apply to an organization? Let’s step out of the technical world and discuss a non-software example of this concept and see if it sheds any light or otherwise simplifies what we are talking about. First, we start with having a look at its opposite, “domain-independent”, and begin with our non-software example.
Let’s step out of the technical world and discuss a non-software example of this concept and see if it sheds any light or otherwise simplifies what we are talking about. First, we start with having a look at its opposite, “domain-independent”, and begin with our non-software example.
Let’s take a pair of scissors as an example.
A pair of scissors is, from one perspective, a domain-independent tool. It can be used to do a lot of tasks and is quite flexible and effective at some things. One can do things that are productive and effective. For example:
One can also do things with scissors that are not productive or effective.
But what if the job at hand is the grooming and maintaining of this:
This, of course, introduces the notion of context as to what something means and how it should be evaluated. This is as it should be.
One way to approach the problem is to apply domain-independent tools (otherwise know as general-purpose tools) to it.
It can be done. Or can it? Let’s take the analogy further. First, let’s have a look at the development team in action.
Right. Something is not quite right about this. Up close, it may even look reasonable but when we consider it further, a number of problems show up. To tackle the golf course with the above techniques you would need a development team of over a hundred people with scissors. You would have to line them all up on one side of the golf course and synchronize the start of the cutting activity (and hope they all cut at the same rate and quality).
Costs of Domain Independent Tools
A few problems arise immediately. One hundred cutters cost money. They probably cut at different rates. They don’t cut very quickly and as such may take days or weeks to get to the other side of the golf course by which time the side of the golf course cut on day one has now grown some and so it is impossible to converge on a “correct” solution in time (the definition of a “correct” here being all blades of grass at the same height within some tolerance). It is even possible that the date and time of the scheduled golf tournament has come and gone in the amount of time it took to “implement” this type of solution and approach.
This is to say nothing so far about the look on the developer’s faces. Some may like doing it but most won’t.
Are we getting it right?
There is even the question of correctness of an individual cutter with this approach. The definition of correct here being, again, all the blades of grass at the same height. What would you have to do to get it right?
And would it be correct? Really?
Perhaps one could hire a correspondingly large number of test and QA engineers to validate, verify the work and handle problems:
So, it takes too long. It’s too expensive. It isn’t even correct (or even correctable). And probably the development team members will not be too thrilled about their jobs. And we missed the market window. Sound familiar? Not good all around.
What is the solution?
You could build your own tools, somehow combining various other domain-independent tools you may have at hand.
Or try to use a powerful but inappropriate tool for the job.
One thing to remember is that, in this scenario, your expertise is golf course maintenance and upkeep, not necessarily tool design and construction. Another approach would be work together with tooling experts and combine your domain expertise with their tooling skills to create the correct tool for the job.
The result of the collaboration would be a professional and effective tool that captures your domain expertise and does the job and solves all the problems we were running into with relying just on the domain-independent scissors.
The analogy here introduces the notion of domain-specific language and domain-specific tools, that is, tools that “speak your language” and work powerfully for your domain. They are not as flexible as the general-purpose tools but get the job done and get it done correctly, in the correct time. The good part about it is one still has the general-purpose tools (the scissors) for the jobs appropriate for those tools.
So, the domain-specific tool approach:
With regard to #5 in the list just above, your development team can point its energy at working on the aspects of the domain and the business that differentiate your company and show it to be better than the competition.
E.g. instead of doing this:
They can be working on these, perhaps more interesting, tasks that are directly related to your domain of golf course design and maintenance:
And with this approach you might even have a bit more time for this:
Sometimes in the high-tech world of software it is useful to consider a non-software example or analogy. In this case we discussed a non-software analogy of the term “domain-specific” as in “domain-specific tools” or “domain-specific language”. While no analogy holds all the way through, this one holds up fairly well and illustrates some reasons to invest in a “domain-specific” approach.
MDE Systems Inc. specializes in Model Driven Engineering (MDE) and Domain Specific Language (DSL) software technologies. Their staff has successfully applied these approaches to many complex and varying domains. MDE Systems has offices in the United States and Europe.
Share this article: