Which fields mark the image in the common model red, and why?

Number, status and amount. Depending on the context, you can mean order or invoice and are therefore ambiguous.

A word like “amount” means something different in two areas. How do you know if your own context makes sense?

Even if rules or responsibility differ, such as the order amount when buying and the invoice amount in the invoice, a limit with translation is worthwhile.

The team wants to roll out every context immediately as a microservice. How do you rate that?

Advantage: clear technical separation. Disadvantage: Operation and network effort are added, although a module in the monolith often carries the boundary sufficiently. Recommendation: first module boundary, service only if specific need.

ConceptChapter I · Domain · Building block 3 of 7

Bounded Context

A bounded context specifies where a professional model and its language apply consistently. At its border, meanings are explicitly translated or assigned.

By Michael Meierhoff · Meierhoff Systems

Own modelEach context defines its own terms.
BoundaryIt determines where a model applies.
TranslationAt the border, meaning is assigned.

Context

Why this is important

The same words do not mean the same thing everywhere in the shop. A bounded context delimits a model and language. It is not a subdomain: it belongs to the problem space, it belongs to the solution space. It is also not a microservice, in the shop a module in the monolith. How contexts are related is shown in the building block context map.

This building block explains business model boundaries. For technical boundaries within the same application, see Module boundaries.

At a glance · Two contexts, one translation

Each context defines its own terms; at the boundary, a translation maps the meanings onto one another.

Shop example · Model division

A model or two?

Order and invoice are two contexts in the shop. Both know an amount and a status, but use these terms for different business purposes.

This is how you read the picture

Own model Order carries order amount, invoice amount; both fields carry only one meaning.
Boundary The boundary separates Order and Invoice, instead of collecting all fields in one class.
Translation From "Order B"-1042 Confirmed" is "Invoice R-882 Open with two assignments.

A common modelClassification Order order

Number: StringConflict: B-1042 or R-882?
Status: angelegt | bestätigt | storniert | offen | gestellt | bezahltConflict: Buy order and claim share a field
Amount: MoneyConflict: Order amount or invoice amount?
Positions: Liste von Positionen
Delivery address: Adresse
Invoice address: Adresse

A status and an amount must carry two meanings; each change on one side meets the other.

Change between a common model and two bound contexts; red marks the fields whose meaning is mixed.

Benefits & limitations

Helps if:

A term is used in different areas with their own rules.
A common model collects conflicting fields or special conditions.

Boundaries

Too many small contexts add cost: every boundary needs translation and coordination. Split contexts when meanings actually diverge; the Context Map makes the effort visible.
A context is not automatically a separate service. In the shop, Order and Invoice are modules in the Modular Monolith; assess their separation through Module Boundaries.

In practice

Explore boundary signals in the process. Use Event Storming with domain experts to examine event sequences, shifts in meaning and related rules. In the shop, 'status' may indicate different models in Order and Invoice.
Record terminology and rules for each area. Gather how domain experts use concepts and which states apply. This makes semantic differences concrete.
Define the scope and owner. State which rules the model covers and which team maintains them. Then choose its technical form using appropriate Module Boundaries.
Design interactions between contexts. Define which data is shared or translated and who owns the contract. A Context Map makes direction and collaboration visible.

Read the detailed explanation

A term can carry different rules and data in different business areas. Within a Bounded Context, one model applies with consistent language and clear ownership. Required information crosses context boundaries through contracts or translation. Domain-Driven Design uses these boundaries strategically; a Context Map describes relationships between contexts.

The domain boundary defines the model's scope; deployment is a separate operational decision. A context may comprise one module, several modules or an independent service. Its technical form also depends on team ownership, scaling and operations. Too many small contexts add translation and coordination effort, while a single global model blurs differences in meaning.

A subdomain describes part of the business domain and belongs to the problem space. A Bounded Context is the model boundary chosen for it and belongs to the solution space. In the shop, they often coincide, for example for invoicing, but need not do so. Domain-Driven Design explains this strategic distinction.

Event sequences and differing terminology suggest possible boundaries, which the team validates with domain experts. Coherent rules, language, ownership and change patterns are decisive for useful boundaries.

Check your understanding

Test yourself in three stages

ReadingCheck in the picture
Which fields mark the image in the common model red, and why?
View the solution with justification
Number, status and amount. Depending on the context, you can mean order or invoice and are therefore ambiguous.
ApplyingTransferred to a new situation
A word like “amount” means something different in two areas. How do you know if your own context makes sense?
View the solution with justification
Even if rules or responsibility differ, such as the order amount when buying and the invoice amount in the invoice, a limit with translation is worthwhile.
EvaluateWeighing an alternative
The team wants to roll out every context immediately as a microservice. How do you rate that?
View the solution with justification
Advantage: clear technical separation. Disadvantage: Operation and network effort are added, although a module in the monolith often carries the boundary sufficiently. Recommendation: first module boundary, service only if specific need.

Explore further

These building blocks continue the thoughts of this page.

References

Continue on the learning path

Next in Domain modelling: Entities & Value Objects.

7 Building blocks

Continue withEntities & Value Objects