In the article “what-is-strategic-design” I made an introduction about what a Bounded Context is.
In this article, I would like to bring a real example so you can have a better understanding.
To remember:
A Bounded Context is primarily a linguistic delimitation, that is to say that terms and sentences can mean different things, according to the context in which they are employed.
This linguistic delimitation refers to ubiquitous language, which is another essential element in DDD.
It is also important to understand that Bounded Context is where the Model is implemented, that is, a Bounded Context is the solution implementation in a technical way.
Practical example
Look at the image above.
You may have noticed that there are two Bounded Contexts and within them there is an ‘Account‘ entity.
It is easy to identify that ‘Account‘ has different meanings in these two contexts.
In the banking context ‘Account‘ refers to subjects such as money, transactions, payments, credit, and may belong to a person or company.
In the context of e-commerce ‘Account‘ refers to subjects such as login, account creation, password change and so on.
With this information we can identify in which context the entity ‘Account‘ belongs even if it had not been told which context it belongs here.
However, reality is often different, and the same entity will be in distinct Bounded Contexts within the same company, and in subjects that look the same. Be very careful with that!
Bounded Contexts and Subdomains
Differences
It is only natural when we start studying DDD that we find content that makes it difficult to differentiate between Bounded Contexts and Subdomains, since they both represent “segregation”.
Vaughn Vernon in his book “Implementing Domain-Driven Design” states that Subdomains live in the space of the problem and the Bounded Contexts in the solution space.
With this it is clear to differentiate that, Subdomains are logical “separations” of the domain and Bounded Contexts are technical solutions.
Relationship
It is desirable that code belonging to a Bounded Context implements a single Subdomain. So we segregate Domain Models by real business intent.
However, this relationship is not always possible, the most frequent reason is when we are working on legacy systems built without the DDD approach, where a single Bounded Context implements more than one Subdomain, this can generate the Big Ball of Mud, which we will talk in future articles.
Teams and Source Code Repositories
I really like the definitions that “Vaughn Vernon – Domain-Driven Design Distilled“, states in his book in summary form:
- There must be a team assigned to work on a Bounded Context.
- There should be a separate source code repository for each Bounded Context.
- It is possible that one team can work in several Bounded Context, but several teams should not work in a single Bounded Context.
See you soon!
