Learning Domain-Driven Design (DDD) — Part 4
A Brief Introduction to Bounded Context
Today I read an interesting article about how ubiquitous language may not be universal in bigger companies and I want to share it with you.
In my last episode about Domain-Driven Design, I wrote about ubiquitous language. Long story short: a language that must be common from developers to domain experts to make communication as easy as possible.
And now it is time for an uppercase BUT.
A domain expert has a single mental model. Two domain experts may have different mental models.
What happens when these two domain experts share some words in their vocabulary? What happens when these common words have different meanings in their mental models?
It happens that the ubiquitous language is not universal in that company.
You cannot use some words expecting to be understood clearly by both of your domain experts. You have to calibrate it, you have to use a set of words when you are speaking about a certain domain (or context) and you have to use a different one when you are speaking about the other context.
Domain-Driven Design defines this way of constraining a specific vocabulary in different domains with the term bounded context.
The bounded context is where the ubiquitous language resides and where the words of that language have a unique meaning.
In your business, you can have many different bounded contexts in which you define a specific, non-ambiguous, ubiquitous language.
I thought this was a very important addition to my previous article.
This is the fourth chapter of my journey in Learning Domain-Driven Design.
I hope you want to actively participate in this journey to mastering Domain-Driven Design. I would love to hear some feedback from you.
Do you know some videos, courses, or other books that I may refer to truly understand this subject? I am waiting for your suggestions! 💚
These are the previous articles I have written about this topic:
