A design approach described in Eric Evans’ “Domain Driven Design” (2003), consists notably of striving to use the vocabulary of a given business domain, not only in discussions about the requirements for a software product but in discussions of design as well and all the way into “the product’s source code itself”.
(Evans’ book details other complementary techniques, but the name “ubiquitous language” conveys the main intention.)
Expected Benefits
One of the problems many software development efforts face is the constant friction introduced by translation between two technical vocabularies, that of the business domain on the one hand and that of the developers on the other.
To some extent this duality is inevitable: developers must frame their work in terms of algorithms and computation, which generally have no direct equivalent in the business vocabulary.
However, the technical vocabulary often tends to “leak” out from reasonable boundaries and take over design conversations to the point where business experts start feeling alienated and disengaged from crucial conversations.
Deliberately and explicitly adopting a “ubiquitous language” policy mitigates these difficulties and is therefore a success factor in Agile projects.
Origins
- 1999: early on in the elaboration of Extreme Programming, the “System Metaphor” practice is proposed to address the issues of business-technical translation and cognitive friction, however, the practice is poorly understood and fails to catch on
- 2003: the term “domain-driven design” is coined by Eric Evans and described in a book of the same name, eventually emerging as a viable alternative to the “System Metaphor”
