how we build · part two

Domain Language and Composition

Domain language is not a coding style. It is a chain attribute — the mechanism by which the brief's meaning survives translation into code. How the code speaks the domain, how components compose, and why developer experience is an investment in chain integrity.

---

Domain language is a chain attribute

The brief uses words. Gal grades. She marks open-answer responses. She submits to the school system. Uri runs a billing cycle. A charge attempt can fail with a failure category. These words are not descriptions — they are the domain language. The language of the people whose situations the software changes.

When the code uses the same language, the chain holds. A function called createExamResult is traceable to the brief. A function called insertRow is not. A table called charge_attempts carries the domain. A table called events_log does not. The language is the carrier — not documentation about the code, the code itself.

// ✗ System language — what the code does
insertRow()          sendMessage()        processQueue()

// ✓ Domain language — what the person experiences
createExamResult()   publishGrades()      retryFailedCharge()

// ADR invariants become named functions
enforceIdempotentSubmission()   // ← the name says: architectural promise here

This is what the Domain-Driven Design literature calls ubiquitous language — a shared vocabulary that is the same in the brief, in the conversation, in the code, and in the tests. The chain does not require DDD as a methodology. It requires that the language travel faithfully. DDD's deeper practices — aggregates, value objects, domain events, repositories — are engineering craft that teams adopt as complexity warrants. The language itself is non-negotiable from day one.

The UI is domain language too

Domain language is not only in the code — it is in everything the person reads. Button labels, field names, empty states, error messages, navigation items. If the brief says Gal publishes grades to the school system, the button says "Publish" — not "Submit," not "Send," not "Sync." If the domain calls it a grading session, the page title says "Grading session" — not "Dashboard" or "Results view." The UI speaks the same language the brief speaks, the code speaks, and the tests speak. When the button says one word and the function behind it uses another, the chain has a language leak — and the person experiences it as confusion.

Next — Bounded contexts and the frontend discipline →