Agile Glossary

Ubiquitous Language

What is Ubiquitous Language?

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”
Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks

Thank you to our Annual Partners​

Join us today!

Agile Alliance offers many online and in-person events and workshops for our members. If you’re not currently a member, you can join now to take advantage of our many members-only resources and programs.

Get the latest Agile news!

  • This field is for validation purposes and should be left unchanged.

By subscribing, you acknowledge the Agile Alliance Privacy Policy, and agree to receive our emails.

Additional Agile Glossary Terms

An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.
A product backlog is a list of the new features, changes to existing features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome.
An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.

Help us keep the definitions updated

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Not yet a member? Sign up now