Development & Code · master area

Domain Language in Code

The named person's vocabulary travels into the codebase. Functions, variables, modules, events, errors — named with the words the brief used, not the words the framework prefers.

Owners: Developer, Tech Lead Phase it lives in: How We Build (Volume IV) The corpus principle this enacts: The code speaks the brief.

Where it lives in the chain

• How We Build · Domain Language and Composition — the canon
• How We Build · Bounded contexts — where the language draws boundaries

How to do this

• Practice — review the Feature Brief before naming the first function. The brief's verbs and nouns become the function and type names.
• Practice — at PR review, the reviewer asks: "could the PO read this filename and know what it does?" If not, the name is wrong.
• Related craft — Content Design — the same words on screen and in code

What good naming looks like

The brief said Gal grades an exam — the code has gradeExam(exam: Exam): GradedExam, not submitForm(data: FormPayload): Response. Events fire as ExamGradedByTeacher, not EntityUpdated. Errors named GradingDeadlinePassedError, not ValidationError("expired"). When the developer chases a bug, they grep for gradeExam and find the bug. When they grep for submitForm, they find sixteen unrelated places that happen to submit something.

The discipline is one direction: brief → code. Code that names things back to the brief — when a developer invents GradingProcessor and the team starts saying "the GradingProcessor" in meetings — has flipped the direction and is shaping the brief instead of being shaped by it.

Related crafts

• Domain Immersion — where the vocabulary is first captured
• Content Design — the surface counterpart
• Code Review — where naming is verified