Skip to content

Domain Immersion

Learning the named person's vocabulary — not just the words but the shape of what those words mean. The same words must travel from the brief, into the code, the API, the analytics events, the support transcripts. One language, end-to-end.

Owners: Whole trio (PO leads, Developer and Designer participate) Phase it lives in: Before We Build (Volume II) The corpus principle this enacts: The code speaks the brief.

Where it lives in the chain

How to do this

  1. Sit with the named person doing the work. Listen for the nouns and verbs they use. Gal says "exam," not "form" or "submission." Uri says "reconciliation," not "matching."
  2. Record the vocabulary in a domain glossary. Term, definition in the person's words, examples of use, related terms, exclusions (what it doesn't mean).
  3. Cross-check — when the brief, code, API, and analytics events use different words for the same thing, stop. That divergence is observation-mismatch waiting to ship.
  4. Update the glossary when the field teaches the team a new word. "After the cycle, we learned that 'completed' has two meanings to Gal — submitted and posted-to-students. Glossary updated."

What good practice looks like

The team's domain glossary is a few dozen terms, alive, dated. It is referenced from:

  • The Feature Brief — terms used in the brief link to glossary entries.
  • The ADR — when a term has technical implications, the ADR records the mapping. "Exam in the domain = ExamAggregate in the codebase = exam table in the schema."
  • Code review — reviewers grep for non-glossary terms.
  • Storybook — component props named with glossary terms.

A new dev reads the glossary on day one and already speaks the team's domain language before writing any code. That is what domain immersion produces. A team without a glossary produces five different words for the same thing across five different artefacts — and the next dev reads each artefact wondering which one is the source of truth.

200apps · How We Work · NWIRE