In this article, I will share my point of view about Bounded Context. I will try to answer questions like what does it mean and why is it required. We will also try to examine the connection between Bounded context and Microservices.
I will try to keep it as simple as possible. This article targets to that audience who will hear the term Bounded Context while developing Microservices but they are struggling to understand the Bounded context concept alone. Before we dive deep into Bounded Context in terms of DDD (Domain Driven Design), let’s understand what is the meaning of that in the real world.
We know that human is the most intelligent species and the latter created different countries for the ruling. But the question is why they created different countries or Logical Boundaries? In what basis boundary has been drawn between two countries? For instance before human civilization, in the Earth there was only land without any concept of country.
One compelling answer that comes to my mind is to separate the administration, culture, laws, economics, so that each country will be able to abstract its people from other countries unless it is an impossible task to create one Unified culture. In ancients times, different tribes have there own languages and cultures.
In the same country, there are some predefined rules that every citizen should follow like language, style etc. For example they understand the common language, they are aware of laws, currency, style, so we can say that Citizens are syncronized with each other in a country and that specific country has one Unified culture which every citizen ought to follow and understand!
In programming, we apply Bounded context in the same manner. In order to separate different models/subdomains from each other in a Domain/Problem space or in a Domain-driven design –Strategic design part, we introduced Bounded context so that in a certain context a model has a certain meaning like the countries we mentioned before which for a particular country–certain language, currency has a specific meaning. But in a different country that currency or language is not understandable, because it has no meaning or it has different meaning in respect to that country. Like the word Fool. For instance in English it means stupid while in Bengali it means Flower !!!!
So if we consider a Country as a Bounded context, and language/currencies as a Model inside that context, we can easily map the concept of the domain model in a certain bounded context. The model has some meaning for a Bounded context but the same model has no meaning/different meaning for another Bounded context. So by Bounded context, we create a logical boundary where the model and business terms have a certain meaning and the Bounded context separate/hide the models from the outer world. All communications should be done via API. So it is obvious that under a Bounded context — model and business logic maintains a certain law and maintain its own persistence storage and that is not directly accessible to other Bounded Context.
BoundedContext Communication
Every design has two common parts, abstraction of the data model and the communication with other parts of the system. By Bounded context we separate the data model in a simple term abstracting the commonalities in the business. But let’s see how one bounded context communicate with others.
Here we will discuss the concept of Context Map. Using Context map we can discover how one Context depends on other Bounded Contexts, like two Context have strong dependencies or one domain sends a confirmation message to another domain (Conformist) or may use a shared kernel/Shared model. I will talk about Context map in a separate article, but for now, imagine that context map is for communicating clearly between Bounded Contexts.
At this point, I believe we covered the fundamental idea of what is a Bounded context, but if you still have questions about how it fits in Architecture you can skip to the next paragraph.
Let’s imagine that we have to design an Online Student management system where students can register to the site choosing their course accordingly, paying their course fee and then they will be tagged to a batch, as a result both Teachers & Students are notified about the batch start date and time slot.
As an Architect, you have to identify the bounded context of the different domain related to this business logic. If we divide the business logic based on related functionality we can find four basic functionalities.
- Registration process: Which takes care of Registration of Students.
- Payment System: Which will process the Course fee and publish online payment status.
- Batch Scheduling: Upon confirmation of payment, this function checks the Teacher availability, batch availability and based on that, it creates a batch and assigns the candidates or it updates an existing batch with the candidate.
- Notification System: It will notify both teachers and students about the timings and slot information.
So, there are 4 bounded contexts Registration, Payments, Scheduler, and Notification. Now let’s dig down how each module represents Teacher and Student and Course Models.
Registration process: It only requires the Student information and it also needs its demographic information like Name, age, sex, address and which course the student chooses. There is no mean of Teacher in this context.
Payment System : It treats Student as Candidates. In Payment System only Student/Candidates financial information is required like for instance the account number and based on the course fees, it deducts the amount from that given account. Thus, here perspective of a student, information needed in payment Service are totally different from Registration, although Payment system may require few pieces of information like name, address of that student, those are just basic information.
The term “Teacher” is not valid here. In payment System Teacher was treated as Faculty and it can be permanent or Contractor based on the Faculty type Payment System. You can choose the payment calculation either per hour basis or per anum basis.
Batch Scheduling: In case of Batch Scheduling System, minimum information is required from Teacher and Student like name, Address etc. But it needs detailed information, of the Course, Batches under the Courses etc.
Notification System: For Notification System, we just need the Teacher and Student email address or Phone number and name. No further information is required. It also needs the name of the Student management system and Course details. Here Student management site acts as Sender and Teacher and Student denotes as Recievers.
Till now we have seen that same Domain Objects like Teacher, Student, Course have different meaning and use-cases for different Context. This is the beauty of Bounded Context. We have also multiple canonical models for same domain Object based on different context in order for developers, business users to be always in the same page when they are talking about a context. The concept of ubiquitous language is woven here. Using ubiquitous language DDD a unified system is created where every participant understands the language based on that context.
Now, the common question is why the Bounded context term is so popular in Microservices?
To answer this question first we have to understand that DDD is applicable for Monolith as well as in Microservice. But in case of Monolith, it is vaguer and more of a logical segregation so only good developers can see it. The main reason is, that in monolith we have a single giant codebase, that may we break it multimodule based on DDD creator ACL/Translator when one module talks to another but still it needs other modules as dependent jars to invoke its method.
Another point is that this is a single code base and multiple coders working on them. So some not so skillfull coders can pollute the boundary or domain Object. In that case Architecht can’t create a physical boundary based on Bounded Context. But in Microservice, architechture is inherented because, as we said, instead of a large code base we can create Small services which have their own code base and services communicate to each other through API or messaging. Thus it’s clear that Business Domain breaks the Business logic in, to multiple Bounded Contexts and each Bounded Context will be a separate codebase which can communicate through Context Map.
To design the Context map you have to design the API carefully. You can use Port and Hub architechture in order your code under the Bounded context doesn’t communicate with Outerworld and thus never polluted. Microservice offers this type of strong segregation of Bounded Context. Bounded Context is more visible and understandable in the context of Microservice.
Conclusion
Bounded Context covers the basic needs when you are trying to break a large business logic. It helps you to understand how different parts of the system use domain objects in a different manner with different terminology. Bounded Context is just a view to properly organize the business logic based on functionality. But in order to make the business logic works — communication between Bounded context is needed, and it uses Context Map for the same reason. In my next article, I will discuss Context Map.
| Published on Java Code Geeks with permission by Shamik Mitra, partner at our JCG program. See the original article here: Bounded Context in my view Opinions expressed by Java Code Geeks contributors are their own. |
