{"id":5003365,"date":"2015-12-17T00:15:27","date_gmt":"2015-12-17T08:15:27","guid":{"rendered":"https:\/\/aadev22.local\/?post_type=aa_glossary&p=5003365"},"modified":"2022-08-30T12:11:04","modified_gmt":"2022-08-30T19:11:04","slug":"ubiquitous-language","status":"publish","type":"aa_glossary","link":"https:\/\/agilealliance.org\/glossary\/ubiquitous-language\/","title":{"rendered":"Ubiquitous Language"},"content":{"rendered":"
\n
\n

A design approach described in Eric Evans\u2019\u00a0\u201cDomain Driven Design\u201d<\/a> (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 \u201cthe product\u2019s source code itself\u201d.<\/p>\n

(Evans\u2019 book details other complementary techniques, but the name \u201cubiquitous language\u201d conveys the main intention.)<\/p>\n

Expected Benefits<\/h2>\n

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.<\/p>\n

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.<\/p>\n

However, the technical vocabulary often tends to \u201cleak\u201d out from reasonable boundaries and take over design conversations to the point where business experts start feeling alienated and disengaged from crucial conversations.<\/p>\n

Deliberately and explicitly adopting a \u201cubiquitous language\u201d policy mitigates these difficulties and is therefore a success factor in Agile projects.<\/p>\n

Origins<\/h2>\n