Domain-driven design, or DDD, is a popular approach to software design that, among various other practices, calls for agreeing on a ubiquitous language. This language is then to be used by domain experts in their requirements descriptions, as well as by software developers in the source code.
A core task of language engineering with MPS (LE for short) is, too, developing a language that the domain experts then use to express their requirements.
What is different between these two approaches?
With domain-driven design, you develop a language and write your software with that language in mind. Your users use this software to do their work, which most likely involves creating and persisting instances of that language. The instances are later queried by the software to produce reports or trigger further logic.
When doing language engineering with MPS, you develop a language, combine it with MPS itself and give your users an editor. The users use this editor to create and persist instances of the language. These instances are later queried to perform analyses and checks or used to generate further code.
DDD: language → software → model (collection of instances of language)
LE: language → editor → model (collection of instances of language) → software → software inputs/outputs
The generated code will usually have inputs and outputs of its own. Thus, LE is to DDD like a higher-order function to a first-order one.
DDD models are data: stored in a database, triggering lifecycle events when added or updated, and there is a single live version (or perhaps a short-lived branch due to eventual consistency).
MPS models are documents: not quite data and not quite code. Stored in a Git repository as XML files, able to be branched and merged. Addition or removal of a model is not (usually) an important event.
Which one is best for your project? The Wikipedia article on domain-driven design quotes the Microsoft Application Architecture Guide which says:
While Domain Driven Design provides many technical benefits, such as maintainability, it should be applied only to complex domains where the model and the linguistic processes provide clear benefits in the communication of complex information, and in the formulation of a common understanding of the domain.
Since language engineering is more complex than DDD, this quote applies to it doubly so: LE should be applied only to complex domains. And sometimes it is necessary to make complex projects in complex domains a reality.