DDD is applied to large and complex business domains instead of simpler ones; it helps by dividing the domain into different bounded contexts, and specifying their interrelationships. The basic idea behind the bounded context is the separation of concerns principle.

Take, for example, a domain of an organization which has departments like HR, Accounts, Regulatory Affairs, and so on. Each has its own responsibility, vocabulary, and different roles, but work together in the principal business domain for a particular industrial vertical. Then these departments can have their own bounded context defined in the DDD model.

Bounded context creates an explicit boundary, and encapsulates or contains a particular model. This model has its own ubiquitous language, which is understood by the domain and technical experts for this model. It is very well possible that the language and vocabulary used in this bounded context has a different meaning in other bounded contexts. For example, a customer in a marketing sub domain might be referred to as a payer in an accounting subdomain.

In DDD, there is a core domain, supporting domains, and generic domains. Core domain is the revenue generation of the enterprise. Supporting domains are to support your core business, like the HR sub-domain. Generic domains are the ones that you need, but you do not worry too much about them. For example, a timesheeting software for a company is a generic domain and is a likely candidate that is bought as an off-the-shelf component.

A bounded context may represent a single sub-domain, while it is also possible that two bounded contexts are implementing a single sub-domain. It is less likely that one bounded context is encapsulating more than one sub-domain; however, it is not a restriction.

There are scenarios where you need communication between two or more bounded contexts. A bounded context does not keep reference of any other bounded context, as it would violate the boundaries principle, and as well as it may also collide the ubiquitous languages between them. The communication between two bounded contexts is normally carried out via domain events; these are event messages (usually asynchronous) that carry only information in the format or language, which is valid in the whole domain. As messages contain the data and not the model, they do not violate the boundaries of the bounded contexts. When one bounded context needs info from another bounded context, it subscribes to its domain events.

Communication can be carried out by one microservice calling another microservice to gather or pass on the information. Another communication case is a service orchestration implementing a certain business process, and which needs to invoke services in several bounded contexts; such activity is carried out by a special process called the process manager, which is not necessarily a business process manager tool. Process managers are not part of any bounded context; they usually carry out the business process across the bounded contexts, because such process managers have are valid at the domain level, which is usually above the subdomains.

The Bounded Context concept is very important for the definition, maintainability, and life cycle of a microservice. It allows us to deal with the relevant model in the protected boundary, which provides both logical and technical limits to the microservice process. This boundary is essential for a microservice for it to be autonomous and self-contained.