Many Ubiquitous Languages

An Ubiquitous Language is used in every place and every time inside an organization... or is it?

Strategic Domain-Driven Design

An Ubiquitous Language is defined by DDD as a terminology gathered, invented and shared by a development team and their business counterparts (both technical and non-technical people). This language is biased towards business terms, coming from the domain the application works on; it is not composed by pattern names such as Factory or Composite but by real world expressions such as Cargo, Route and Itinerary (examples from Evans's blue book).

Strategic DDD concerns itself with the higher-level design of a project, especially with the division of it into multiple Bounded Contexts: separate applications that collaborate together (via remote procedure calls, HTTP, messaging, whatever) to achieve business goals such as selling a good to an end user, deliver it and check his satisfaction.

The divide-et-impera motto of Strategic DDD is usually both more important and more aggressive than we thought: where we see 4 Bounded Contexts a deeper analysis may reveal easily twice the number. The kind of separation preached by DDD allows:

• putting different teams to work on different Contexts.
• Outsourcing or buying some of the Contexts.
• Scaling the application in scope by segregating the complexity into different Contexts instead of coding up a Domain Model where classes contain several dozen fields.

The Ubiquitous Language follows the Bounded Contexts

One of the realizations spawned by Vaugh Vernon's new DDD  book is that it is customery for the Ubiquitous Language to follow the Contexts. It is difficult for the classes of a Domain Model and for a database to scale to cover the whole of a project; the same happens to the terminology. So giant classes are separated field-by-field and remodeled into multiple classes into different source code repositories; and the names of classes and methods should follow the same separation.

I once thought of a domain as a large scale environment where the application lived, such as chemicals or transportations or payments; by now, I have understood there are many subdomains in each of these businesses that we can map our contexts on.

Trying to use a single language to capture multiple domains will make for a very large glossary, but it's not even the worse aspect. Like we'll see in the next example, multiple languages allow for a term to have multiple meanings depending on the context it is used in. That explains for once the term Bounded Context: not a catch-all word for lack of a better name like in the Servlet API, but the limit of applicability of a term for it to maintain a precise meaning.

In fact, the language and the multiple meaning of a word (such as our subscription example) can help defining contexts, by following the areas of the code and the business processes where a term has a consistent meaning and where it ceases to work and become something else.

Subscriptions

Take the word subscription, in the sense of magazine and service subscriptions. In a very broad context and Ubiquitous Language, it will represent a recurring (daily, weekly, monthly) transfer of money between two parties, a user and a merchant (these terms come from one of our Ubiquitous Language at Onebip.)

However, when you dig deeply and develop a Service-Oriented Architecture composed of several services each containing a Subscription class, you find out more.

• in the front end, a subscription is an object containing a representation of the button used for activation by the user, along with its IP address for tracking.
• in the engine that decides when to bill subscriptions in the weeks after activation, the subscription has very few description fields (such as the country) and most of its behavior is related to renewal, retry and termination dates and policies.
• in the connectivity component, finding sources of funds for a user and billing them, a subscription is just a URL: http://www.onebip.com/api/subscription/42. It is used as a container identification for all the money transfers authorized by external systems.
• in the administration panel, subscriptions often appear with all of these data exported together, or as aggregates by country or merchant.

I bet we could find more meanings for subscription with more contexts to work on; these are some of the currently existing ones.

Conclusions

Vaugh Vernon completes the picture on multiple subdomains with the red book on DDD: each subdomain and corresponding aligned Bounded Context has its own Ubiquitous Language, which can be analyzed to define the boundaries themselves. It's not the language following established boundaries as much as the contexts being deined by the different languages in an organization.
Applying these techniques to brown-field projects is going to be difficult, let's not kid ourselves. But if we're going to take a step, it's better that be a step in the right direction and not down a slope...