Bounded Context

The founding strategic DDD pattern: a model is consistent inside a boundary, and inconsistent the moment you cross it without translation.

Problem

In a large EDI hub, the word "order" does not mean the same thing depending on who speaks. For purchasing, it is a PurchaseOrder with status "open / approved / delivered" and carries the buying promise. For finance, it is a contractual obligation that creates an Invoice. For logistics, it is a Despatch with delivery dates. When one tries to model "the order" as a single global JSON schema unifying everything, each team fights to impose its fields: 60 attributes, 30 conflicting enums, a team paralysed at every change.

Forces

• Business language diverges between teams. An "approved order" means buyer-validated (purchasing), but booked as commitment (finance), but ready to ship (logistics).
• Release cycles differ. Purchasing ships monthly, finance quarterly, logistics continuously. A common model blocks everyone.
• External constraints differ. Purchasing negotiates with suppliers, finance complies with accounting standards, logistics optimises fleet.
• A universal model does not exist. Trying to build a unified model ends up producing an empty object: each team ignores the others' attributes.

Solution

Identify the domain's bounded contexts, give them explicit names (Purchasing, Invoicing, Logistics, Audit), and define for each its own business model — its ubiquitous language. At context boundaries, set up a Context Map: explicit translators (Anti-Corruption Layer), negotiated shares (Shared Kernel), conformist or customer-supplier relationships. Each context-owning team evolves its model at its own pace.

┌────────────────────────────┐         ┌────────────────────────────┐
│ Purchasing context         │         │ Invoicing context          │
│ ──────────────────────────  │         │ ──────────────────────────  │
│ PurchaseOrder              │ ──ACL──▶│ Invoice                    │
│   poNumber : "PO-12345"    │ Trans-  │   invoiceNumber : "INV-99" │
│   buyerId, supplierId      │ lator   │   debtor, creditor         │
│   deliveryDate             │         │   paymentTerms             │
│   "open", "approved"       │         │   "to issue", "sent",      │
│                            │         │   "paid"                   │
└────────────────────────────┘         └────────────────────────────┘
   EDIFACT ORDERS D.96A                    EDIFACT INVOIC D.96A

EDI implementation

Concrete case: a hospital EDI hub separates the "Patient Administration" context (HL7 ADT, where "patient" is an administrative identity with address, social coverage, next of kin) from the "Clinical Orders" context (HL7 ORM, where "patient" is an exam subject with weight, allergies, active prescriptions). The two contexts share only a pivot identifier (MRN). An Anti-Corruption Layer (translator) maps ADT^A08 to the models needed in Clinical Orders. Similarly in retail: EDIFACT ORDERS (purchasing context) ≠ ASN/DESADV (logistics context) ≠ INVOIC (invoicing context). Each context has its team, its validation rules, its partnerId mapping. The EDI hub is the Context Map infrastructure.

Anti-patterns

• Big Ball of Mud. A single flat model shared by all teams: every change breaks others, nobody is responsible.
• Contexts matching the org chart. Contexts must follow business coherence, not HR structure. Otherwise the boundary shifts at every reorg.
• Contexts without explicit boundary. If we do not know where "Invoicing" ends and "Purchasing" begins, concepts leak (order silently becoming invoice without translation).

Related patterns

• Anti-Corruption Layer — the defensive translator at context boundaries.
• Ubiquitous Language — the shared language inside a context.
• Aggregate — the transactional consistency boundary inside a context.
• Canonical model — the technical translation between contexts/partners.
• Data Mesh — Dehghani's generalisation of Bounded Context to the data world.

Sources

• Evans E. — Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley 2003. Chap. 14 "Maintaining Model Integrity" — the original definition of Bounded Context.
• Vernon V. — Implementing Domain-Driven Design, Addison-Wesley 2013. Chap. 2 and 3 develop the strategy of slicing into contexts. informit.com — Implementing DDD
• Fowler M. — BoundedContext (martinfowler.com 2014). Pedagogical synthesis of the pattern. martinfowler.com — BoundedContext
• DDD Crew — Context Mapping. The visual companion to Bounded Context. github.com/ddd-crew/context-mapping