Using the vocabulary of a given business domain in discussions of design as well, not only in discussions about the requirements of a software product is a design approach that is described in “Domain Driven Design” by Eric Evans. Besides “ubiquitous language”  there other complementary techniques but the main intention is that language.

 

Expected Benefits

One of the problems that are already expected on many software developments because It happens all the time is the constant friction introduced by translation between two technical vocabularies,  the business domain on one hand and 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 disengage from important conversations.

 

Deliberately adopting a “ubiquitous language” policy assuage these difficulties and is a success factor in Agile projects.

 

Origins

1999: early on in the elaboration of Extreme programming (XP), the “System Metaphor” practice is proposed to address the issues of business-technical translation and cognitive friction, however the practice is not understood as it should 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 good alternative to the “System Metaphor”.