What is Bounded Context?
Bounded Context is one of the core patterns in Domain Driven Design and is about how we divide a large project or team into domains. It also provides basic information on how to divide the project into microservices when we use a microservice architecture. Although there is no specific rule in this regard and it is necessary to do this work with more business knowledge and experience, Bounded Context shows us a method. Basically, it is necessary to design the parts that do independent work as separate microservices as much as possible.
Here comes the question of how big or how small. If we design microservices as large, we actually do not get far from monolithic implementation and we do not use the advantage of creating independent sections by dividing the work into smaller parts by designing microservices. If we make very small microservices, there is a dependency between microservices that should not exist. In fact, the increase in common codes among microservices is an indication of incorrect division of microservices. It is conceivable to design common codes as a separate microservice. For example, if customer-related controls are carried out in more than one microservice, it may be considered to write the control microservice separately.
Bounded Context does this division work on the differentiation of spoken concepts. Using the concept of ‘Ubiquitous Language’, Bounded Context states that there must be a common language in order to be a separate microservice. In different units of a large company, a different language is developed over time by using words wisely. Systems in which a common language is formed are determined with experts, who may also be from the business unit and designed as a separate microservice. As an example, in the example below, the concepts of Customer or Product are different for Sales and Support teams (there will be common properties too, of course). For the sales team, in order to predict which products the customer can buy, the customer class retains the properties including the customer’s age, job, previous purchases, but for the support team, only the address information and what products s/he bought is enough to provide after-sales support. Based on this differentiation in customer concepts, sales and support are separated as separate domains according to the Bounded Context structure. Of course, the work done and the corporate culture are a very important factor in this separation.
The figure above illustrates the relationship of the possible classes for the sales and support microservices.
References
