The Importance of Ubiquitous Language

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 goal is 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 is Not Just Developers, but Also Includes the User Domain Experts

Software projects set out with the goal to solve a problem or perform a desirable function. It doesn'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 compared to taking out a full-page ad in the Sunday edition of the Los Angeles Times. They'd organize their suggestion and take it to a supervisor. If the supervisor liked the idea, they'd take it to their boss. Eventually, the project would go to the end of the queue of the IT department.

Sooner or later, maybe, the developers installed 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, 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.

That 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 the Program Works With

Whether it's 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 that defines the 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?

The only right or wrong would be to come up with the model for 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 developer will ask questions the domain expert will have to think about in a more 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.

It's so important because it dictates the design of the domain, and everybody's thinking around the boundaries of the project problem. The project exists within a bounded context which 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 knows 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 makes sharing of 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 are where they do not exist or where they're 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.