Introduction
Explanation of the concept of bounded context by Greg Young.
Explanation of bounded context with an example
Greg provides the example of the word "Déjeuner" in Canada, where French is the second language. In this context, the word means breakfast. In France, however, it means lunch. This illustrates how language divides and changes the meaning of certain words, creating a clear boundary of meaning between languages.
This behavior is also noticeable in the company we work for. An example could be an insurance company. The insurance company uses the term policy.
Example of a bad bounded context
Here is an example of a poor implementation of a bounded context, where the term policy aggregates many meanings from different departments of the company:
Sales Department:
In the view of the sales department, a policy is the final product. A salesperson sells the policy and receives a commission from the sale.
Claims:
In the context of claims, a policy refers to an automated claims system where 90% are handled online.
Call Lock
This is a mechanism that blocks the insured's premium, protecting against premium increases.
Claims History:
A record of all claims.
Shareholders:
Shareholders do not view the policy as a single element. They look at a set of policies, calling it a "risk pool." Sometimes they look at an individual policy, but only in terms of risk assessment and profit.
Improved bounded context for the sales department
A good implementation of a bounded context only for the sales department:
Sales Department:
- The salesperson sells the policy
- The salesperson receives a commission from the sale
What happens if we start using the term policy, understood in the context of the sales department, in another department, for example, with shareholders? Why do we, as programmers, create our own definition of a policy?
In our example, we are dealing with the existence of three pervasive languages. The first pervasive language exists in the limited context of shareholders, the second in the sales department, and the third in the context of claims. For each of them, the term policy is completely different.
Greg makes an interesting point: bounded context is a linguistic problem, not a technical one. We seek definitions that differ from each other.
It is possible to find the boundaries of contexts in just 6 days (about a week). You can simply go and ask the relevant departments in the company what they understand by the term policy. Start grouping the words. Write them down.
- Sales Department
- Claims
- Accounting
- Intranet
- Shareholders
- Marketing
After you’ve written them down, go to the business and ask one simple question. What level of competitive advantage does each item on this list provide?
If our company does not have infinite resources, it means that the company’s money should be used optimally. We should pay attention to areas that will yield a return on investment and dedicate less time to areas that do not ensure a return. Domain-driven design is an expensive process because we need to perform analysis. We only conduct analysis in key areas of the business.
So, how do we determine where to spend time on analysis? Ask your business to rank the items that will provide a competitive advantage over others.
- Sales Department -> S(small)
- Claims -> L(large)
- Accounting -> S(small)
- Intranet -> S(small)
- Shareholders -> S(small)
- Marketing -> S/M(small/medium)
An additional question we can ask is: Can we immediately buy a product that will do this for us? If so, then compared to other companies, we do not stand out at all, which gives it a small ranking. We can ask an additional question. What will be the return on investment for each of these models?
In the second stage of our categorization, we ask the following question: What is the technical complexity of implementing a given model? We write down small, medium, or large next to the first question. This simple approach allows us to quickly diagnose where to shift our focus and implement a given business model.
- Sales Department -> S(small)
- Claims -> M/L(medium/large)
- Accounting -> M/L(medium/large)
- Intranet -> S(small)
- Shareholders -> L(large)
- Marketing -> S/M(small/medium)
The chart clearly shows us what we should dedicate most of our time to in analyzing and applying domain-driven design. Look at the location of the claims dot. The complexity level of the model ranges between medium and large. Furthermore, the claims model gives our company the greatest competitive advantage. Since we are able to handle 90% of our claims online, this represents our advantage.