Bounded Contexts and the Language That Reveals Them

Domain-driven design, from Eric Evans' 2003 book, is often reduced to a catalogue of object patterns. That is the smaller half. The half that changes systems is strategic: the claim that a large domain cannot be modelled by one consistent model, and that trying is the root cause of the unmaintainable enterprise application.

The clearest way to find contexts is to listen for a word that different groups use differently. In a logistics business, "shipment" means a customer promise to sales, a set of physical parcels to the warehouse, a customs declaration to compliance, and a line item to finance. A single `Shipment` class serving all four ends up with sixty fields, of which each caller uses eight, and every change to it requires four teams to agree.

// Before: the business rule is invisible, and no domain expert can read it.
policy.status = 4;
policy.statusChangedAt = new Date();
if (policy.premiumsPaid < policy.premiumsDue) policy.flagged = true;

// After: the code says what the business says, and the rule lives in one place.
const lapsed = policy.lapse(clock.now(), LapseReason.NonPayment);

// Inside the entity:
lapse(at: Date, reason: LapseReason): Policy {
  if (this.status === PolicyStatus.Cancelled) {
    throw new DomainError('A cancelled policy cannot lapse');
  }
  return new Policy({ ...this.state, status: PolicyStatus.Lapsed, lapsedAt: at, lapseReason: reason });
}

Context mapping: naming the relationship

Once you have several contexts, the relationships between them need naming, because each relationship is a different commitment about who accommodates whom. This is context mapping, and it is as much an organisational statement as a technical one.