The definition of the bounded context comes directly from the domain-driven design principles. When applied to the microservice

architecture, it outlines the boundaries of the business subdomain each microservice is responsible for. The bounded context

becomes the foundation of the microservice contract and essentially serves as the fence to the external world.

The cumulative business domain model of the whole application constitutes from the domain models of all its microservices,

with bounded context in between to glue them together. Clearly, if the business domain is not well-defined and decomposed, so

are the domain models, boundary contexts and microservices in front of them. 

Bounded Context is a central pattern in Domain-Driven Design.

 It is the focus of DDD's strategic design section which is all about dealing with large models and teams.

 DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.

https://martinfowler.com/bliki/BoundedContext.html

A bounded context is simply the boundary within a domain where a particular domain model applies. Looking at the previous diagram, we can group functionality according to whether various functions will share a single domain mode

Shared kernel: This is when two bounded contexts share a subset of the domain model. While this technique is easy and intuitive, it can be hard to maintain, since the two teams managing the different bounded contexts must agree on any changes, and in any case, the risk of breaking functionalities in the other context is always present, so every change must be thoroughly tested (automatic is better).

Customer supplier: This is similar, in a way, to the shared kernel approach, but the relationship here is asymmetrical. One of the two bounded contexts (the supplier) will own the interface, developing and maintaining the features, while the customer will simply ask for what is needed. This simplifies the synchronization a bit between the two teams. However, it can still create issues when priorities and milestones start to clash.

Conformity: This shares the customer-supplier type of relationship. The difference here is that the customer domain model completely adopts and imports a subset of the supplier domain model, as it did in the shared kernel approach. However, unlike shared kernel, the relationship stays asymmetric. This means that the customer cannot change (or ask for changes in) the shared model.

Anti-corruption layer: This is a different approach. In this case, there is a translator layer between the two domain objects. This layer acts as a demilitarized zone, preventing objects and behaviors from sneaking from one bounded context to another. This approach is commonly used when dealing with legacy applications, more than when two bounded contexts belong to the same application. 

https://www.linkedin.com/pulse/why-bounded-context-crucial-micro-services-manish-mehndiratta-togaf-/