Domain Specific Languages 2.0

When new software application is built most of the time is spent on communication. Huge amount of knowledge must be transferred between users' representatives and IT specialists. There are different approaches that try to cope with this process. They mainly differ on the number of translation steps and therefore documentation complexity. In terms of knowledge management documented process or system has an advantage – all acquirements are available for further reference.

Unfortunately documents just after creation usually become outdated. The knowledge transfer happen not only when requirements are expressed or application code is designed. Significant number of facts is revealed also during acceptance tests and even production maintenance. These are rarely included into reference files created during earlier stages. Documents ends life just after first lines of code is written.

Advantage of Domain Specific Languages

System implementation in general purpose languages (like Java) causes that business information is encoded into technical statements. The business context is lost because of the fixed language vocabulary. Variable naming is not effective enough to keep the knowledge intact, neither is it easy to understand. In theory, multi-tier architecture helps to maintain the same kind of information in one place, but usually is not sufficient to answer any detailed questions quickly and without any doubt.

Domain specific languages approach is a step in the proper direction. The vocabulary fits particular domain so that the final effect doesn't vary from what ordinary users can say about a particular application aspect. This process simplifies the development process - reduces the number of translation steps and encourages further development assisted by a business representative (understand-implement-test cycle). A natural consequence of this is that the duty of documenting is dropped - the implementation is the documentation.

Reusing DSL artifacts

Code readable by non techies or up-to-date documentation are equal. None of them can be created by business but it can be business readable. Both simplify impact analysis of any change request and both can be reused in next projects. Co-workers can learn and build new ideas on it, keeping business and technical aspects growing together.

Another story is when information contained in DSL code is applicable in other part of system. Assume statements of insurance product definition describing optional risk covers. These apply directly to user interface – each option should be available for selection. Product definition and user interface are autonomous system domains but with certain scope overlapping.

Lost in wealth

When number of artifacts is significant then searching proper piece become hard. To apply an information (the knowledge) effectively it must be found precisely basing on semantic context. It is elementary when you provide a system for a business but rarely considered for IT itself.

Natural approach is build a service that exposes needed information parts at a runtime. When a new business need appear new service will be built. It solves problem only on a system level. People should be supported when looking for DSL artifact the same way as customers can query on customers in CRM.

Summary

Precise and predictable artifact querying is what human need and system implement. Domain Specific Languages simplifies development process and introduces knowledge management as a main part of it. Building a bridge between business and IT based on DSL is not effective without adding semantic querying of information – both for people and systems.