We need to find concepts that suits the situation of our problem. The process is usually iterative and depends on the domain size, our knowledge and situation stablility, may take several iterations. We should assume that most of the searched concept already exists, and can be found through talking with the stakeholders. It's important because people are familiar with their language are hesitant to learn new one. We are interested only in those concepts which allow us to describe the variation of model, but we have to take under consideration that it can be described also after connecting the elements to each other.

Try to find modeling concepts in:

·         Architecture

·         Existing products

·         Specifications

·         Patterns

·         Existing code, libraries and frameworks

The next step is mapping the domain concept on modeling language. In this step during design we deal with the problem if we making a static modeling concepts, or leaving decision about it to modeler. (How varied the language will be) It's worth to hint that latter decisions may bring difficulties in integration of models, tests, and creating code generator. If we decide to express variation in language we can use:
·         separete modeling object
·         propoerty of object
·         relationship between objects
·         property of relationships

As most of the concepts are limited with some rules, we have to take them also under consideration. They play important role as they prevent from errors, check complettness, and ease modeling work by using patterns and default values. But being strict on requesting our rules is sometimes in conflict with usability of language. So it's also good to think when we want to check, deny just after prohibited step, or maybe inform that we will trigger a conflict in model. The example of most important rules are:
·         Uniqueness of elements
·         Mandatory propoerties
·         Occurrence of relationships

As far as visual representation doesn't matter during generation it's highly relevant for usability of our language. We can choose different representation forms, like models, matrixs, tables, where each of them have their strengths and weakness. Elements also can be represented by different kinds of symbols like text, sign or photo. It's also good to ask our modelers to come up with their symbols for domain concepts.

Early tests of new language ensure us about right direction of development. It's good to use many real life examples done by developers who earlier builded applications within our domain. We can check for example if:

• there is higher abstraction level
• is specification consistent with language rules
• aren't rules too strict
• do we need all the concepts