This chapter is from the book
This chapter is from the book
This chapter is from the book
Benefits
Now that we've looked at some examples, we can see the benefits of Domain-Specific Development.
- A DSL gives the ability to work in terms of the problem space, with less scope for making the errors that come from representing it in a general-purpose language.
- Working in terms of the problem space can make the models more accessible to people not familiar with the implementation technology, including business people.
- Models expressed using DSLs can be validated at the level of abstraction of the problem space, which means that errors in understanding or representation can be picked up much earlier in the development lifecycle.
- Models can be used to simulate a solution directly, providing immediate feedback on the model's suitability.
- Models can be used to configure an implementation consisting of multiple technologies of different types, which can reduce the skill and effort required to implement a solution using these technologies.
- Models can also be used to generate other models, and to configure other systems, networks, and products, perhaps in combination with other enabling technologies such as wizards.
- A domain-specific language provides a domain-specific API for manipulating its models, thus improving developer productivity.
- The artifacts generated from a DSL need not all be technological implementation artifacts; a suitable model can be used to generate build scripts, purchase orders, documentation, bills of materials, plans, or skeletons of legal contracts.
- Once important business knowledge is captured in a model, it becomes considerably easier to migrate a solution from one technology to another, or between versions of the same technology. This can often be done simply by modest modifications to the generators or interpreter.
In combination, these factors can offer considerable increased agility. For example, in the software defined radio domain mentioned earlier, Bruce Trask reports that "users of the tool report a minimum of 500 percent increase in productivity."
Of course these benefits are not free. To get them, you must invest in designing and building a DSL and integrating it into your overall solution. This will involve the cost of development—which is considerably reduced using DSL Tools. But it will also include costs for testing, deployment, documentation, staff training, development process modifications, and so on. When setting out to implement a DSL you must balance these costs against the expected benefits. You'll get the benefits when the costs can be paid off from the benefits of applying the approach to lots of systems. Hence the approach is particularly attractive to Systems Integrators, who often have to carry out many similar software development engagements for one customer after another. For a small company that does not specialize in particular business areas, it may be worth investing in DSLs that describe technological domains, such as web services and databases; for a larger company that is vertically organized into industry specializations, it may also be worth investing in DSLs that describe corresponding business domains.