Bounded context
In large applications, there are many models without clearly defined dependencies. As the system develops, the boundaries between models blur and the links between objects become unclear. For example, when working on a new functionality, two teams work with one model. Often, communication between teams is occasional, which results in conflicting interpretations of the model. Creating a pattern leads to longer working hours as well as to unclear relationships in the model itself.
Errors in the source code are more often found in a system with too many relations and vaguely defined limits. Then the source code becomes unreadable and difficult to understand. Communication between teams is getting more and more difficult, and models blur their destiny.
To solve these problems, you need to define Bounded Context. This is the most fundamental principle in Domain-driven Design. It consists in dividing large models into smaller entities by drawing clear boundaries and mutual relations. Each context should have clearly defined and understandable for all Ubiquitous Language. To determine the bounded context, consider what the system is responsible for and how it is divided.
Two teams working on the same system used in the online store create functionality responsible for sales and customer service. By sharing the code and objects between the two teams, a very big mistake is made because the teams do not work on the same bounded context. Risking future complications related to system modifications resulting from unforeseen dependencies between models.
Information about system modeling should be provided to teams working on different parts of the system. The purpose of sending notifications is to determine the relationship between models and to define appropriate communication between bounded contexts. In doing so, great care should be taken to ensure that these relations are clear and clearly defined.
Defining the system in this way has one very important advantage: transparency. Lack of common models gives a sense of greater certainty by lower probability of breaking sensitive relationships. Each attempt to communicate between bounded contexts should be discussed along with the benefits and the damage resulting from their connection
In summary, bounded context is a certain area within which there is a clearly defined domain model. The microservice structure assumes that each bounded context is a separate project.
