Bounded Context is an important domain driven design (DDD) concept, although its implementation can be extremely complex. It can be a technical solution for good domain modeling.

Bounded context defines the scope of each model and ensures consistency of the domain model in each bounded context.

In his book, Vaughn Vernon wrote that bounded context is primarily linguistic demarcation. That is, terms and definitions can mean different things based on the context where they apply.

This distinction refers to a ubiquitous language, which is also another main element in DDD.

Bounded context features

• Each context can have its own architectural approach (application layers, persistence, infrastructure, etc.).
• Any bounded context can have its own way of saving. For example, relational, memory or cache storage, and the like.
• Any bounded context has its own single language.
• Context architecture does not have to be in a domain model template, it can use both a three-level model and implement Command and Query Responsibility Segregation or CQRS, Event Sourcing, etc.
• A bounded context can be developed by different development teams. It is not necessary for only one command to know the implementation of all contexts, on the contrary, for security reasons, the source of the bounded context may be limited to a specific command.
• Restricted contexts can interact with each other in several ways.

Context Cards

There will be relationships and interactions between teams that will inevitably manifest themselves in an appropriate bounded context. A context card is a common type that represents relationships between different commands. The context card contains several templates to represent the relationship between a restricted context:

Common core

Several restricted contexts depend on this type of context. It cannot be changed without consulting all the developer teams that depend on it.

Client/Developer

The subordinate team acts as the client for the superior team (developer). Client contexts depend on the developer context. Both sides agree on the requirements, and then the superior team completes the construction and development of the model and transfers it to the subordinate team for further use. Joint debugging and testing takes place. This model is based on friendships and team support.

Conformist

This is a scenario in which client and developers disagree with each other. Thus, the client is forced to use what the developer has provided in his business, even if it does not meet the needs. The client must accept this fact and come to terms with it.

Partner

In this case, the two teams depend on the context of both sides. They need to make efforts to model the project to help each other.

Protection against corruption

In this template, clients develop an additional layer of anti-corruption protection to reduce the influence of developers. This is a typical situation where the model of the superior team is not friendly and not suitable for the subordinate team, but they must rely on this model.

Open Host Service

In this case, special services are offered that everyone can use. That is, the team can provide access to the group of services to other teams. This is especially useful when integration with many other systems is needed and when implementing these integrations is too time consuming.

Separate paths

When the relationship between the two teams is optional. They can evolve and be modeled independently of each other.

The concept of bounded context must be applied to differentiate the behavior of a domain based on its intentions, giving a clear understanding of what should be developed independently and what should be shared.