Getting started

The idea of DSM is to generate full code of software on the base of abstract model of problem. Using practice can be easily integrated into classical Open Unified Process. Practice introduced DSM workshops which can be prepared by during work on architecture, and be a investigation if stakeholders, our team accept the concept. During rest of the phases we incrementaly build domain language, framework and code generator.
First we create very small and narrow meta-model and try to use it in company, it will be itself a proof of concept and check if it's possible to use the concept in specific domain. It's good idea to use working example during dsl workshops.
Then we create pilot product which embrace the wider part of selected domain, on this stage even if project fail we still take profit of deeper understandin our project domain.
From this point we try to use our new language in project, incrementaly improving it. New requirements may show up, and the domain will probably also change due to the changes in law. The key of effectivity is to keep the right proportions between domain language, framework and generator.

 Common pitfalls

Wrong domain
DSM cannot be used in every type of projects, There is a need of using it in solutions witch varies but are designed in the same narrow domain, like on board computers in car industry.

Inmature domain
Creating Domain Specific Modeling Language requires maturity of selected problem domain. Domain which is poorly recognied is very often problematic in defining domain specific language, which also causes problems in genating final code.

Wrong level of abstraction
Due to the lack of experience in practice and domain, we can define the language which will be on too high or too low level of abstraction. In both cases gathering informations from model by a generator will be a problem.