Bounded Context
Last updated
Was this helpful?
Last updated
Was this helpful?
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 of Bounded Contexts are:
Order context
Delivery context
Invoice 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 .
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.