Bounded Context

A Bounded Context is a logical boundary whiting a system where ubiquitous language is applied. It encapsulates a set of services which share the same deployment cycle or domain model.

Ubiquitous language is implemented by specific canonical models representing a same domain object in different contexts. Different canonical models are required, as a total unified domain model for a large system is often not feasible or cost-effective. Unambiguous language helps developers, businesses, and users to stay on the same page when they are talking about a context.

Examples

Examples of Bounded Contexts are:

• Order context

• Delivery context

• Invoice context

How to design a bounded context

With one large context everything becomes equally critical, it is not possible to have redundancy in one part of the system, changes to a functionality can potentially affect others.

Bounded contexts help to structure complex logic in services that can be easily understood so that it is possible to:

• Contain Complexity

• Easily define and implement transnational boundaries

• Allocate critical features to different contexts

• have a small number of Team understanding and owing each context.

In traditional DDD application a Domain Model is a shared resource that the Bounded context consumes across all Application Services, Repositories and Domain Services. If we decide to implement the Application services layer using microservices architecture, then we require to make sure each services can be deployed independently. This can be achieved using Aggregates.

Event Driven System and Bounded contexts

When we Implement an Event Driven Systems along side a Domain Driven Architecture we introduce the concept of Domain Events.

An example of Domain Event for the Order context is Order accepted. The Invoice and the Delivery contexts are interested in the occurrence of this event as it causes some internal processes to be started.