Bounded contexts (DDD-lite)

One claim number follows the claim through the call centre, the loss adjuster, finance and the supplier desk.

At the claims office	In bounded contexts
"the loss" is the event to the call centre, the covered damage less the excess to the adjuster, the money reserved and paid to finance	one term, a meaning per context (steps 1–2)
each desk keeps its own form; nobody fills one giant form for all four	a model per context, none for everything (steps 2–3)
every form carries the claim number	contexts share the id (step 4)
the supplier's quotes come in its catalogue codes; the supplier desk turns them into the insurer's item categories and asks the supplier to change nothing	an anti-corruption layer (step 12)
when the supplier renumbers its catalogue, only the supplier desk's code list changes	the change lands in the layer (step 13)
the wall chart of desks, what passes between them and where it is translated, as the office works this year	the context map (steps 8–9)

In real terms: each context's code keeps its own model of a shared thing, joined to the other contexts by its id, and an outside model is translated in one place.

Breaks down when: a desk can phone the supplier to ask what a code means. A translation layer has nobody to ask, so a code it does not map must be refused or flagged in code.

Contrasting case: a one-person plumbing firm takes the call, fixes the pipe and sends the bill. One person speaks one language, so one context is right.

4.1 ExamHall EXH-2360: one Attempt class for three teams

EXH-2360: Proctoring, Grading and Billing shared one Attempt class. Billing asked to charge sittings that a proctor voided after more than 20 minutes, and a developer widened the class's isComplete(), which Grading also calls. The script runs five attempts; a-4 was voided at minute 25:

4.1 shared Attempt, before Billing's change: graded a-1, a-2, a-3 · charged a-1, a-2, a-3
4.1 shared Attempt, after Billing's change to isComplete(): graded a-1, a-2, a-3, a-4 · charged a-1, a-2, a-3, a-4

Grading graded a voided attempt (step 3). MR !2660 gives each team its own model, built from Proctoring's session record and joined by attempt_id, and moves Billing's rule into Billing's model:

4.1 MR !2660 a-4 as proctoring.Session: attemptId, candidateId, centreId, state, minutes, deadline
4.1 MR !2660 a-4 as grading.Submission: attemptId, answers, final
4.1 MR !2660 a-4 as billing.Charge: attemptId, centreId, minutes, chargeable
4.1 MR !2660 after Billing's change to Charge.chargeable: graded a-1, a-2, a-3 · charged a-1, a-2, a-3, a-4

One attempt, three shapes and one shared id (step 4). Billing's change now stays in Billing.

4.2 Proof domain, media streaming: three counts of "subscribers"

One week of a streaming service's accounts, counted by three teams, each with its own meaning of "subscriber":

4.2 "subscribers" this week: Billing 2 (paying accounts) · Playback 5 (profiles that streamed) · Marketing 3 (newsletter emails)

Each count answers its own team's question correctly. One word with three meanings asks for three models (steps 1, 5).