As in anything new, the quickest way to learn it is to do some background reading, talk to someone who is experienced, and try out some simple tutorials or examples. Hopefully the information and links on this website will lead you in the right direction.
To get to a situation of domain-specific modelling with full automatic code generation, you must provide three things: a domain-specific modeling language and editor, a domain-specific code generator, and a domain-specific component library. For any realistic chance of being able to achieve these, you need an expert: a good developer who has already developed several products in this domain, developed the architecture behind the product, or has been responsible for forming the component library for the product.
A domain-specific component library is not always necessary, but it makes the task of code generation development significantly easier. Often, code components already exist from earlier development cycles, at least in the form of reusable pieces of code. Further developing these pieces of code into true components is a relatively easy task for the expert, requiring only the normal developer programming tools.
In addition to domain-specific components developed in-house, the library can of course contain generic third-party components. Whilst the component library here is thus nothing new, the fact that it will be intrinsically part of the development process ensures that the components there will actually be used.
A harder task is the development of the domain-specific modeling language; the concepts and notation the end user will build his model with. The experience and intuition of the expert, combined with hints from the component library, domain rules and architects are the real sources of clues. The expert should also consider the issue of code generation, which will be his next task: a good mapping from the domain metamodel to combinations of components will make that much easier. Metamodelling languages can be applied here to describe both the domain rules and their mappings.
In the creation of a DSM language, the support offered by the DSM toolst is vital. A toolset that allows rapid prototyping is practically a necessity: the expert can then make a part of the metamodel as a prototype, and instantly test it by making an example model. Similarly, the more the toolset can automatically make of the finished modeling environment, the better: the expert can then concentrate on the hard problem of developing the method, and the modeling tool implementation of it, with all its menus, toolbars, icons and behaviour, is instantly and automatically available.
With a good DSM construction toolset, then, the main work is in establishing the content and structure of the method: the toolset makes creation of tool support for the method a simple task, of the order of a day or two. Without such a toolset, the time to add tool support for the new DSM language will be measured in man-years.
The code generation definition forms the final task, conceptually if not chronologically: in practice there will be a large degree of parallelism and incrementality between all three tasks. In this phase the expert specifies how code using the components can be automatically generated from the structures in the users' models. The DSM tool should provide the necessary functionality for creating such generation scripts, and should guide the expert where possible by allowing him to reference and use the concepts in the metamodel.
Of all the phases, code generation probably varies the most between domains. In some domains it will be possible to produce a large fraction of code with a relatively simple code generation scripting language, such as is already provided in most DSM toolsets. In other domains, it may be necessary to use a more powerful language to operate on data exported from the modeling tool. The most important goal is that the end user should be able to use the code generation simply: the cost of developing the code generation is then defrayed over many users.