Bounded Context

A bounded context defines a boundary within which a domain model and its terminology have a specific, consistent meaning. In Domain-Driven Design, it helps keep models focused and prevents the same term from acquiring conflicting meanings inside one model.

A bounded context is a conceptual boundary around part of a business domain. Inside that boundary, a team agrees on the meaning of domain terms and maintains a consistent model of the relevant business rules.

The same word can legitimately mean different things in different bounded contexts. For example, `Customer` in a Sales context might represent someone who places orders, while `Customer` in a Support context might emphasize support cases and contact information. These contexts do not need to force those models into one shared class.

A bounded context is not necessarily a Java package, microservice, database, or deployment unit. Those technical structures can implement a bounded context, but the boundary is fundamentally about domain meaning and model consistency.

Bounded contexts are particularly useful when a large domain contains multiple teams or business capabilities. Explicit boundaries reduce accidental coupling and make it clearer where concepts belong and how different models should communicate.

When two bounded contexts interact, Domain-Driven Design describes their relationship through a context map. Integration can use mechanisms such as APIs, events, or translation layers, depending on the needs and relationship between the contexts.

Key points

• A bounded context defines where a particular domain model and terminology apply.
• The same domain term may have different meanings in different contexts.
• A bounded context is a domain boundary, not automatically a microservice or Java package.
• Context boundaries help reduce model complexity and accidental coupling.
• Interactions between contexts can be described using a context map.

Interview questions

How do bounded contexts communicate with each other?

They can communicate through APIs, domain events, messaging, or other integration mechanisms. The design should make the boundary explicit and avoid silently sharing internal domain objects. A translation layer, sometimes called an anti-corruption layer, can protect one model from concepts that belong to another. A context map helps document these relationships and the chosen integration approach.

What is a bounded context in Domain-Driven Design?

A bounded context is a boundary within which a domain model and its terminology have a defined meaning. It keeps concepts and business rules consistent inside that boundary. The same term can have a different meaning in another bounded context. The goal is to avoid forcing unrelated models into one overly broad domain model.

Can two bounded contexts have a class with the same name but different meanings?

Yes. For example, Sales and Support may both have a `Customer` concept, but each model can contain only the attributes and rules relevant to its context. The important requirement is that the meaning is clear within each boundary. Sharing one class purely to avoid duplication can create unwanted coupling between models.

Is a bounded context the same thing as a microservice?

No. A bounded context is primarily a domain concept, whereas a microservice is a technical deployment boundary. A microservice can implement a bounded context, and in some architectures a bounded context may span multiple technical components. The correct mapping depends on domain boundaries, team ownership, operational requirements, and integration needs.

Why might different bounded contexts model the same business entity differently?

Different contexts have different responsibilities and business rules. A Sales context may care about ordering and pricing, while Support may care about contact history and service cases. Combining everything into one model increases complexity and couples changes that do not need to change together. Separate models allow each context to evolve according to its own domain needs.