Domain-Driven Design: Tackling Complexity in the Heart of Software

Domain-Specific Languages
An interesting approach that is sometimes declarative is the 
domain-specific language.
In this
style, client code is written in a programming language tailored to a particular model of a
particular domain. For example, a language for shipping systems might include terms such as
cargo
and 
route
, along with syntax for associating them. The program is then compiled, often into
a conventional object-oriented language, where a library of classes provides implementations for
the terms in the language.
In such a language, programs can be extremely expressive, and make the strongest connection
with the 
UBIQUITOUS LANGUAGE
. This is an exciting concept, but domain-specific languages also
have their drawbacks in the approaches I've seen based on object-oriented technology.
To refine the model, a developer needs to be able to modify the language. This may involve
modifying grammar declarations and other language-interpreting features, as well as modifying
underlying class libraries. I'm all in favor of learning advanced technology and design concepts, but
we have to soberly assess the skills of a particular team, as well as the likely skills of future
maintenance teams. Also, there is value in the seamlessness of an application and a model
implemented in the same language. Another drawback is that it can be difficult to refactor client
code to conform to a revised model and its associated domain-specific language. Of course,
someone may come up with a technical fix for the refactoring problems.
From the Ground Up
A different paradigm might handle domain-specific languages better than objects. In the
Scheme programming language, a representative of the "functional programming"
family, something very similar is part of standard programming style, so that the
expressiveness of a domain-specific language can be created without bifurcating the
system.
This technique might be most useful for very mature models, perhaps where client code is being
written by a different team. Generally, such setups lead to the poisonous distinction between
highly technical framework builders and technically unskilled application builders, but it doesn't
have to be that way.
In the scheme programming language, something very similar is part of standard programming
style, so that the expressiveness of a domain-specific language can be created without bifurcating
the system.
[ Team LiB ]

---

[ Team LiB ]