Let’s talk today about Bounded Contexts in DDD. We might be wondering: if a context is bounded, then is it a subdomain? At least that was the first thing I thought. 🤔 💭
But, before getting into the definition, we need to understand the problem.
In the latest post, we were talking about ubiquitous language in Domain-Driven Design. This is the language that allows all stakeholders to communicate with each other using the same terms (remember, always use business domain-related terms, not technical jargon!) to avoid misunderstandings. But what happens if the same term has different meanings in different parts of the system?
Let’s give an example
Imagine a library management system with two departments: Inventory and Loan Management. Here, we have the term “book” but with different meanings 📚
🔹 In the Inventory context, a book is a physical item stored on the shelves.
🔹 In the Loan context, it refers to a borrowable unit that a member can check out.
In real life, when people talk within their specific context, it is easy to align on the meaning of “book.” However, when designing a system, this is not the case. 🗣
This is essentially what a Bounded Context is. It allows you to separate the concept of "Book" in Inventory Management from the concept of "Book" in Loan Management, helping to avoid confusion and maintain clarity within each part of the system. In essence, it structures the ubiquitous language with the rule that it must remain consistent within the scope of the bounded context. Across different bounded contexts, the same term within the domain can have different meanings.
So what is the difference between a Bounded Context and a subdomain, then? 🤯
Subdomains are discovered in the analysis phase (remember: we first analyze all the subdomains: core, generic, and supporting) of the business, while bounded contexts are designed. There may be a 1-to-1 relationship between a Subdomain and a Bounded Context, but it’s also possible for a subdomain to contain multiple bounded contexts.
On the technical side, bounded contexts allow us to have a physical boundary. This means that each can be implemented using the technology stack that best fits its needs, enabling independent deployment and development, and allowing teams to work autonomously.
🔴 An important point is that a bounded context should be implemented, evolved, and maintained by a single team.
I know that you are already thinking about microservices architectures, we will talk about that! 👾
That’s it for today. Hope you learned more about DDD.
Have a lovely day! 🌅