Domain-Driven Design Community

More interaction between the DDD and DSM communities is long overdue.

DDD offers a whole number of valuable techniques that make software developers better modelers, and that give domain experts a sufficiently strong voice in the development of software.

DSM in turn offers advanced techniques for modularizing large domains, and for exploiting ubiquitous language and domain specific frameworks to the fullest.

I would summarize the relationship between the two approaches as follows: DDD creates a deep understanding of a domain from a software development perspective, wheras DSM captures and modularizes raw domain expertise in a form that domain experts and software tools can interact with directly.

The core strength of both DDD and DSM is the focus on domain knowledge, and an independence of specific run-time implementation technologies. Yet both approaches run the risk of being hijacked and diluted by technologists. In the case of DDD the risk originates from the implementation technologies that the project team is familiar with, which exert a subtle pressure on domain terminology; whereas in DSM the risk is associated with the tooling used for capturing modeling language definitions and for expressing the mapping between domain specific models and underlying execution platforms.

Experienced DDD practitioners are well aware of the need to concentrate on the core domain when developing and validating the ubiquitous language, so I'll only say a few words on technology related risks in the context of DSM, as these risks may seem larger to outsiders than they really are.

Firstly, DSM tooling is problem analysis and product design-time tooling, and is unrelated to the run-time technology stack of the applications being built. Secondly, formal meta models (language definitions) and models expressed in these languages (written and read by domain experts, and automatically translated into running code) take the concept of ubiquitous language to a new level. The main risk to consider is potential lock-in to specific analysis and design-time tooling. But the impact of this risk is actually quite small, and should not be blown out of proportion: DSM tooling is all about executing and transforming formal models, and it therefore provides all the self-help needed to automate the process of switching to different DSM tooling to a very high degree.