What is a “Bounded Context”
When defining the requirements of business there are processes that are related.
They consume common data but their responsibilities are related to a specific business requirement.
An example of a Bounded Context that most companies would have is the Customer Management context.
This image shows the bounded contexts of a typical company that provides a delivery service of manufactured products.
The Customer Management Context is bounded by the Entities and Value Objects that support its Single Responsibility to the Business Domain.
The Vendor Management Context is bounded by the Entities and Value Objects that support its Single Responsibility to the Business Domain as well.
DDD’s Model Driven Design
… Creates Boundaries around Identified Business Processes
…… That Encapsulates the Data, they Require
The Domain Business Processes are represented as Domain Entities while the Data State Objects are represented as Value Objects.
A Bounded Context can be accessed only from a Bounded Context Root Entity called the Aggregate Root.
The Aggregate Root Behavior Class is the only Reference that any Consuming Method can hold to the Bounded Context
The collection of State Objects, the value objects that hold related data, can only be accessed by a call through the Aggregate Root.
This Design Access Rule Protects the Integrity of the Data in the Value Objects
The real benefits of Entity and Value Objects can be better understood when comparing the two Bounded Contexts: Customer Management and Vendor Management.
Concluding Thoughts
The modern business model generally requires an Enterprise Domain that can be very complex.
When all of the elements of the domain is attempted to be displayed and understood as a single holistic view it is difficult for the average human being to grasp the enormity of the business model in a single view.
Business domains are actually a collection of related Entities that relies on common processes and resources.
These related Entities generally can perform their responsibilities as an atomic unit.
They can be represented as functional units that have Responsibilities and consume Dependencies.
The Domain Driven Design concept of the “Bounded Context” creates structures that represent the business functional units in a way that allows an Architect to represent the development arenas requirements for the Technological Domain Code Base.
The Bounded Context acts as an anti-corruption boundary that protects the integrity of the data structures it manages.
With the constraint of a single point of access by any consuming Client, the Aggregate Root, a bounded context becomes a manageable collection of related business processes and resources.
How Do You Eat an Elephant
A Sandwich at a Time
Wisdom Pearl # 123 – Organize Your Creations
A Place for Everything
… And Everything in Its Place
…… Organize Your Creations by their Behaviors and Responsibilities
The following two tabs change content below.
I am a Principal Architect at Liquid Hub in the Philadelphia area specializing in Agile Practices as a Certified Scrum Master (CSM). I use Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD) with Behavior Driven Development (BDD) as my bridge to Agile User Stories Acceptance Criteria in a Domain Driven Design (DDD) implementing true RESTful services
Latest posts by Brad Huett (see all)
- DevOps: A Bridge to Your DevOps Culture - March 25, 2016
- Embracing Test Driven Development (TDD) - March 25, 2016
- DevOps: Delivering Agile Projects - March 25, 2016