How Do You Identify Bounded Contexts in DDD?

How Do You Identify Bounded Contexts in DDD?

In Domain-Driven Design (DDD), a Bounded Context is an explicit boundary within which a particular domain model, terminology, and business rules are valid and consistent.

The key to identifying bounded contexts is to discover where business concepts, rules, responsibilities, and language change meaning—not simply where the application has different modules, APIs, or databases.

For example, in an e-commerce system, the word Product can mean different things:

• In the Catalog context, a product has a name, description, images, and specifications.
• In the Inventory context, a product is something with stock quantities and warehouse locations.
• In the Sales context, a product has a selling price, discounts, and eligibility rules.

These may be related concepts, but they don't necessarily belong to one shared domain model.

1. Seven Techniques for Identifying Bounded Contexts

1. Identify Business Capabilities

Start by understanding what the business does, rather than how the software is currently organized.

For an e-commerce business, capabilities might include:

• Product Catalog
• Pricing
• Inventory Management
• Order Management
• Payment Processing
• Shipping and Delivery
• Customer Management

Each capability is a candidate bounded context, not an automatic one. Some capabilities may belong together, while others may need to be divided further.

2. Look for Changes in Business Language

This is one of the strongest clues.

Ask business stakeholders and engineers what important terms mean in each part of the business.

Business Term	Catalog Context	Inventory Context	Sales Context
Product	Product description and specifications	Stock-keeping item	Sellable offering
Available	Published and visible	In stock or available to promise	Eligible for sale
Price	May show a reference price	Usually not the main concern	Selling price after pricing rules
Status	Draft or published	In stock or out of stock	Active, discontinued, or not orderable

When the same word has materially different meanings, rules, or lifecycles, that suggests separate models and potentially separate bounded contexts.

3. Identify Business Rules and Invariants

A business invariant is a rule that must always hold within the relevant domain model.

For example:

• Inventory: A stock reservation must not exceed the quantity available for reservation.
• Order Management: An order cannot be confirmed unless its required validation rules are satisfied.
• Payments: A payment must follow the permitted payment-state transitions.
• Shipping: A shipment cannot be dispatched until the required dispatch conditions are met.

Ask:

• Which rules must be enforced together?
• Which business decisions belong to the same responsibility?
• Which rules change independently?
• Which team or business function owns these rules?

Rules that need to be consistent and evolve together often belong within the same bounded context. Different business responsibilities with distinct rules may indicate separate contexts.

4. Look for Different Lifecycles

A useful way to identify boundaries is to examine how business objects change over time.

Order Management Context

Created
   |
   v
Confirmed
   |
   v
Completed

Shipping Context

Created
   |
   v
Dispatched
   |
   v
Delivered

An order can be confirmed before a shipment exists, and one order may result in multiple shipments.

Even though these concepts are connected, their lifecycles and business rules differ. This is evidence that Order Management and Shipping may deserve separate bounded contexts.

5. Identify Ownership and Decision-Making Boundaries

Ask who makes the business decisions and who is responsible for the outcomes.

• The Catalog team decides how products are described and published.
• The Pricing team owns pricing policies and discount calculations.
• The Inventory team owns stock availability and reservations.
• The Shipping team owns shipment execution and delivery status.

If business rules, terminology, and change requirements are independently owned, separate bounded contexts may be appropriate.

However, different teams alone do not prove that separate bounded contexts are necessary. Team structure should support the domain model, rather than dictate it.

6. Examine Integration Points and Data Ownership

Look at how business capabilities communicate.

Suppose the Order Management context needs product details from Catalog and stock availability from Inventory.

Instead of sharing all internal domain objects, each context can expose a clear contract containing only the information other contexts need.

For example:

• Catalog publishes product information.
• Inventory provides availability or reservation operations.
• Order Management coordinates order placement.
• Shipping receives fulfillment requests after the appropriate business conditions are met.

If a context must understand another context's internal rules or database structure to function, its boundary may be unclear.

7. Use Domain Events and Event Storming

Event Storming is a collaborative workshop technique in which domain experts and developers explore business processes using domain events, commands, policies, and actors.

For an order-processing flow, events might include:

• ProductPublished
• StockReserved
• OrderPlaced
• PaymentAuthorized
• ShipmentDispatched
• OrderDelivered

During the workshop, look for clusters of related business activities, different terminology, distinct lifecycles, and handoffs between responsibilities.

These clusters can reveal candidate bounded contexts. Validate them with domain experts rather than treating the workshop output as a final architecture decision.

2. Worked Example: Identifying Bounded Contexts in an E-Commerce System

Suppose you are designing an e-commerce platform. Start with business capabilities, then identify the models and rules each capability owns.

• Catalog Context: Product descriptions, categories, and publishing.
• Pricing Context: Prices, promotions, and discount rules.
• Inventory Context: Stock, reservations, and availability.
• Order Context: Order placement, validation, and order lifecycle.
• Payment Context: Payment authorization, capture, and refunds.
• Shipping Context: Fulfillment, dispatch, and delivery tracking.

These are candidate contexts for illustration. A real domain investigation may combine or split some of them.

How Do You Validate These Boundaries?

Take the proposed Order Context and ask:

1. Does it own the rules for placing and confirming orders?
2. Does it have a clearly defined order lifecycle?
3. Does it need its own model of an order, separate from a shipment or payment?
4. Can it interact with Inventory and Payment through explicit contracts?
5. Can its business rules evolve without requiring changes to unrelated contexts?

If the answers support a coherent model and clear responsibilities, the proposed boundary is worth validating with the domain experts.

3. Bounded Context vs. Microservice vs. Module

These concepts are related but not interchangeable.

Concept	What It Defines
Bounded Context	Where a particular domain model and its language are valid.
Microservice	An independently deployable software service.
Module	A logical unit of code within an application.

A bounded context can be implemented as a module in a modular monolith or as one or more services, depending on the requirements.

For example, you might initially implement Catalog and Pricing as separate modules in one application. If they have distinct models but do not need independent deployment, that can be a reasonable design.

Do not create a microservice for every bounded context automatically. Deployment, operational complexity, team ownership, scalability, and reliability requirements should also influence that decision.

4. Common Mistakes When Identifying Bounded Contexts

• Dividing contexts only by database tables: Tables describe data storage, not necessarily business boundaries.
• Creating one context for every entity: A Customer, Product, or Order entity does not automatically need its own context.
• Treating every team as a context: Team boundaries and domain boundaries may differ.
• Sharing one universal domain model: The same business concept can have different meanings in different contexts.
• Creating too many contexts too early: Excessive fragmentation increases integration and coordination costs.
• Treating contexts as permanent: Boundaries can evolve as business understanding improves.

5. A Practical Checklist

Use these questions during domain discovery or architecture workshops.

• We understand the business capability and its purpose.
• The terminology and domain model are coherent within the proposed boundary.
• Business rules and invariants have clear ownership.
• The main entities and their lifecycles are understood.
• Responsibilities are distinct from neighboring contexts.
• Integration contracts and dependencies are explicit.
• Domain experts agree that the boundary reflects how the business works.

Final Takeaway

The most reliable way to identify bounded contexts is to combine business capabilities, ubiquitous language, business rules, entity lifecycles, ownership, and integration boundaries.

Start with candidate boundaries, discuss them with domain experts, and refine them as you learn more about the business. The goal is not to create the maximum number of contexts; it is to establish clear, cohesive models with well-defined boundaries.