The implementation design must be easily and accurately mapped to the model, otherwise the model is of little use. Easier said than done though.
Anyway, the process should start by creating a simple but very accurate design of a small part of the domain. This inicial design should then be revisited, improved, incremented and re-factored in order to reflect a bigger set of the domain, in a way more suited to the actual implementation.
Although there should be specialized roles specific to some members of the project team, the responsibility for analysis, modelling, design and programming must be shared amongst all developers and domain modellers. If a developer does not develop the domain model, he will not feel ownership of the model, will not know it, will not use it, and, as such, his code will not reflect the domain mode. In the same way, if a domain modeller is not developing part of the implementation he will be cut off from the challenges, inaccuracies, and details that the implementation process puts to light, and will not be given the chance to re-factor the model so that it reflects the domain.
More over, by compartmentalizing responsibilities, collaboration and the corresponding knowledge transfer between developers and domain modellers is disrupted.
Through knowledge crunching, a team distils a torrent of chaotic information into a practical model. A model driven design initially connects the model and the implementation. The Ubiquitous Language is the channel for all that information to flow between developers, domain experts and the software.
@hgraca 