At first, ubiquitous language (UL) sounds like a science fictional, trans-galactic version of Esperanto. In real life, it’s a tool for teams of domain-driven-design software developers.

Just as the vocabulary of a natural language such as English or Tagalog defines and shapes the thinking of people who speak that language, UL defines the thinking of the team on a development project.

The difference between languages we acquire as babies and in school and UL is that first the team must define the project’s UL. To a degree, it’s as though you invented your own language to express your own views of the world. However, unlike the private languages invented by some small children, UL enhances communication between all team members involved with a software development project. It requires all team members to participate. The goals are clarity and specificity.

Eric Evans first used the term in his book Domain Driven Design. He stresses how important it is for all team members to use the model as the backbone of the UL, and that all team members must use the UL exactly in all contexts: coding, writing, diagrams, and speech.

The team includes not only developers, but also the user domain experts

Software projects set out with the goal to solve a problem or perform a desirable function. They don’t exist in a vacuum. Somebody, whether a client company or another department, needs their computer to do something useful.

Back at the dawn of the computer age, the folks in the marketing department would discuss how useful it would be to have all the contact information for marketing channels. Maybe they wanted to compare the cost of running radio ads in New York City during rush hour with that of taking out a full-page ad in the Sunday edition of the Los Angeles Times. They’d write up their suggestion and take it to a supervisor. If the supervisor liked the idea, they’d take it to their boss. Eventually, the project land at the end of the IT department’s work queue.

Sooner or later, maybe, the developers would install the program. However, the marketing department could not compare the cost of reaching different demographics, the user interface made their heads hurt, and when they requested a report, it printed out three extra pages of useless boilerplate.

The software programmers were not “wrong.” They did a technically good job with the program. But they didn’t know marketing or what the marketing department users needed. And in many corporations, the culture did not allow for cross-departmental communication. Higher management had to approve the plan and then put in the request. The vice-president of marketing knew marketing but not the small-chunk nuts and bolts of what the computer interfaces did or looked like. Therefore, they could not communicate their department’s needs to the head of the IT department.

These kinds of miscommunications eventually led to methodologies of software design that included the end user as an intrinsic member of the team.

The domain is the business subject matter that the program works with

Whether it involves marketing, accounting, or analyzing stock market investments, the project exists to solve a specific problem for a specific business. The domain expert is the end user who understands what the marketing department requires.

Software architects don’t understand marketing, but they know how to develop a program to do what the domain expert needs.

Domain-driven design requires communication between the software experts and the domain experts

Before coding, the team must build a model of the domain, to define the problem. They must combine their expertise to create a mutually understood vocabulary for describing that problem. Then the software team can work out the model as a set of concepts to use software to express.

The core domain is unique to the business, and there will also be various subdomains supporting it.

Developing a program to analyze the cost-effectiveness of various marketing channels requires a lot of variables. The team has to define those exactly.

Commercials on television stations? Network, or local affiliates, or independent? What about cable channels? Treat HBO differently than a channel packaged with basic service? What about YouTube and Vimeo?

What distinguishes “right” terms from “wrong” ones is whether they help the team come up with a model that is effective and efficient for what the marketing department needs to use the program for.

However, the team needs to define every variable exactly. Much of the terminology will reflect domain jargon, but that’s not required, and some marketing lingo varies from expert to expert. In this process of software model discovery, the developers learn about the core business they are working with or for. And to obtain a clear understanding of the domain and the problem to solve, the developers will ask questions that the domain expert will have to think about in a detailed, analytical way. The project team must work together to define exactly what they mean by every term.

And that’s the ubiquitous language.

In extreme programming (XP), it’s a system of names.

This ubiquitous language is so important because it dictates the design of the domain as well as everybody’s thinking around the boundaries of the project problem. The project exists within a bounded context that will need to communicate with other domains. For instance, this marketing project will be more useful if it compares actual products’ sales, so the company can tell which channels, customer demographics, and types of marketing appeals are most effective at selling the product.

With the domain model created and the UL agreed upon, the software engineers determine which technologies they need to use to create the program.

The UL of one domain can overlap with others to increase communication between them

When bounded contexts share a UL, that’s a published language, and it makes sharing data easier. However, there is only one UL per bounded context.

UL is sort of like the structure of a complicated crossword puzzle. It's not the solution, but it defines where there are spaces for letters and where spaces do not exist or are blacked out. UL is important for setting the terms for software developers and domain experts to solve the problem.

At Stride Consulting, we’re your technology partners. As agile software development specialists, we’ll help you create a terrific product. Contact us today.