Understanding the Relationship Between a Ubiquitous Language and Bounded Context in Software Development
What is a Ubiquitous Language, what is a Bounded Context, and why one cannot live without the other.
Bounded Context
A Bounded Context is a semantic contextual boundary.
Vaughn, Vernon. Domain-Driven Design Distilled
All the software components included in a specific Bounded Context have a clear meaning. That meaning is referred to the context itself. Outside of that context, the meaning might be different.
This is true in both directions: outside-in and inside-out.
Terms and definitions created inside the Bounded Context might not keep their meaning when used in a different context. The same applies to terms and expressions outside of the Bounded Context. The meaning of such terms cannot penetrate inside of the Bounded Context.
A single team must own each Bounded Context.
The same team can own multiple Bounded Contexts. However, having different teams responsible for the same Bounded Context is problematic. The problem is about dependencies.
Having one Bounded Context owned by more than one team creates a strong dependency between the teams.
Ubiquitous Language
The Ubiquitous Language is a set of terms and expressions referring to a specific part of the business.
It holds the knowledge of that business section and is contextual. The terms and expressions of the language are coupled with the context of that specific business section. The exact terms referred to a different part of the business might not keep their meaning.
So, what does “ubiquitous” mean?
In this case, ubiquitous doesn’t mean “valid everywhere.” It is ubiquitous for the team using it, and it must also be reflected in the artifact produced by that team.
The Ubiquitous Language is documented by the team’s speech and the source code.
You can create documentation for the language, but it would be hard to maintain. The Ubiquitous Language can change frequently. It follows the evolution of the system it describes.
The best documentation for the Ubiquitous Language is the source code and the team’s people.
The Language and the Context
There is no Bounded Context without Ubiquitous Language.
A Bounded Context is defined by its components. Each component has its meaning that must be expressed by the terms used in the language. Without a defined language, it becomes hard to clarify the responsibilities of a specific component.
When components have no clear responsibilities, they can’t have clear boundaries.
Let me give you an example. Consider an e-commerce system with one part dedicated to managing orders and another to payments. Do these parts represent two different Bounded Contexts, or are they the same? It depends; in our example, let’s consider them two separate Bounded Contexts.
Let’s add a component; don’t think of it as a specific piece of code; consider it a generic part of the logic.
Does it belong to the Order or the Payment?
Someone might say it belongs to the Payment context because it speaks about “Transaction,” which is true. In the Payment context, it might be related to the transaction confirmation when we connect to a payment system like Stripe or Paypal. So, in the payment context, it seems clear that it refers to the confirmation that the payment transaction is coming from another system.
What if I told you that the “TransactionConfirmation” component might also belong to the Order context?
In the Order context, that component refers to the confirmation of the payment received from the Payment system. So, in the Order context, the “transaction” refers to the entire payment process.
Transaction confirmation can have different meanings depending on the context in which it is used.
