In the introduction of this chapter, we already touched on the topic of linguistic differences of the same language. If one language is divided by some kind of boundary, would this be a geographical, national or professional area, it starts to split. We used British and American English as an example before, but of course, there are more examples like this. Dutch language spoken in Belgium is often even referred to as a separate language, Flemish, because it sounds quite different but especially because for everyday objects and actions different words are being used. Same can be observed for languages that evolve within professional groups, where people develop jargons and we have looked at some examples of this too.

These examples were presented here not only to demonstrate how important it is to define the precise meaning of words. Avoiding confusion indeed is one of the goals to find and identify the ubiquitous language.

It is important to realize that ubiquitous language is only valid within a context. Another context is defined by a different language. There is a misconception that ubiquitous language is called ubiquitous because it is the single language for the whole business, organization or domain. This is not the case. It is ubiquitous not horizontally, but vertically. Each context might have its own language, but all layers in this context share one Ubiquitous Language – meetings with the business, models, code, tests, UI concepts, data structures, and so on.

Let's have a look at the classic example of the term Product being used in different contexts of the e-commerce domain:

Although we are operating in the same domain, clearly the product term has somewhat different meaning in each of the identified contexts:

• Sales: For the sales people, product means the sales price and maybe the margin. It's where the company earns money, and other properties of the product aren't that important.
• Purchasing: If we buy a product to resell, we are most interested in the purchase price, how many items of a given product the supplier has in stock, and how fast they can be delivered.
• Inventory: It is most interested in how many items we have in stock. In case if a specific item is out of stock, this context can keep the estimated date when it will be back in stock. Here we probably also define some internal properties of the product like the item number.
• Warehouse: It needs to manage the space required to store products, so they need to know when product batches arrive, when shipments to customers take place, how products are packaged and where they are stored.

As you can see, although we got a popular term, such as product, different departments in the same domain, or organization, really have very little shared interest and have more in-depth knowledge in their subset of properties of something, that otherwise could be considered as the same object.

Another good example would be the term Policy in the insurance domain. It is a bit less known for people that do not work in insurance, but in general, we understand that people that sell insurance to us are mostly interested in money and in getting new customers. So for them, the policy means new sales and money. When it comes to approvals, if we take vehicle insurance as an example, the policy means risk. Even after a policy is sold, there is a chance that the risk assessment department could request additional documentation and after some internal checks, reject the policy. And finally, when it comes to the point of handling a claim on the existing policy, for the claim handling department it is a cost since the insurance company loses money.

Both examples demonstrate that even for the same domain there is a different context where language changes and sometimes changes significantly. What happens, if we keep using the same meaning of words across contexts? Well, obviously things become much less explicit. The degree of ambiguity increases with each new context that we fail to identify and separate. This leads to unclear models and as the result of unclear code, where we need to clarify, what do we mean exactly when we use this and that word.

Mixing different contexts in one working environment also leads to something called context switching. In Quality Software Management: Systems Thinking, Gerald Weinberg suggested that increasing number of projects, which one individual work on, lead to significant productivity loss due to context switching:

Adding one more project to current tasks means 20% productivity loss. Hence, when the number of contexts reaches five, the amount of time spent on the actual work becomes tremendously low. Most of the time is then spent figuring out in which context the current task belongs.

It is valid not only for the project. You might know from experience that for larger projects where generalization prevails over precision and unambiguity, the phenomena of context switching effects the performance just as much. In our Product example, if we would put all properties of different logical views of the product in one place, working with such object would involve some additional effort of trying to understand on which part of the product we are working at the moment. So despite this still is one thing, the hidden context switching and productivity will respectively suffer.

Assuming that centralization and generalization are good things, many software systems create so-called God classes, like customer or product, which contain all possible properties for all possible views of a physical object. In addition to context switching, there are more downsides to such an approach.

One is obviously that not all properties need to have value during a specific lifecycle of such object in the system. For example, the phased-out product has no features related to sales whatsoever. But since we have one class for everything, we must assign empty values to all these properties. Such approach leads to high degree of confusion since we hardly understand why these properties are vacant - either there is a mistake in the system, or this is just a typical situation due to the object state.

Another issue is that inevitably such classes attract a lot of dependencies. You probably have seen data models, which sometimes mimic as domain models, where the whole complex system has one large SQL database where tables have many crossing references. We could imagine that thing like Product can be referenced by Order, ShoppingCart, Catalogue, Invoice, PurchaseInvoice, Return, CreditNote and so on. The model becomes tangled and very hard to maintain. Sometimes it gets worse because referential dependencies sometimes are plain wrong. For example, it is not correct to show an updated product description on some order from the past. The order should contain a snapshot of a purchased product as it was at the moment of purchase.

Probably we have identified enough reasons for us to be cautious not to forget about context when seeking the language. Ubiquitous language is always unambiguous, explicit, and context-specific. As soon as you sense or observe that meaning of words starts to change between different parts of the system, this should trigger an alarm in your head that you are probably crossing the context boundaries.

Context emerges when discussing users: Developer love to think about people as users. This term is so ambiguous that it is almost guaranteed that we switch between different contexts when talking about users.

Our developers discussed how their users would rate their deals. They thought that it could be useful if people can give a rating to each other, helping to build trust in the community. During the conversation, some of them noticed that they use words user, those who sell, seller, those who buy and buyer interchangeably. When the generic term user was used, it almost always required clarification, what role this user plays at that particular moment. At the same time, when they named their users as buyers and sellers, there was no ambiguity and no further clarification was required.

After noticing this, the group decided that they discovered new elements of the Ubiquitous Language and started to use these terms. It was a good insight that saved them a lot of time when they discussed models and also removed ambiguity in code.

At the same time, splitting people into sellers and buyers in the authorization part of the system made no sense at all. These were just users, and the can log in to the system and do some operations, like update their profile, without any clear distinction if they are going to sell or buy on the site. It was another context when the word user was not ambiguous and was explicit.

Later they discovered another distinction for users when they modeled the back office system. There, users started to take roles, and again ambiguity was there until they identified these roles and began to use terms like administrator, support assistant, and reviewer. A new context was discovered, and a new model emerged for that context, being separated from other contexts by the meaning of words.