capturing-the-domainlisted

# Capturing the Domain ## Overview Software fails most often because the model in the code does not match the model in the experts' heads. The cure is not more documentation; it is a shared mental model, expressed in the same words in conversation, in the types, and in the function names, with no translation step anywhere. Discover the domain through what happens, not through what things are. A list of nouns produces a database schema; a list of events and the commands that cause them produces a design. ## When to use - Starting a new feature, service, or bounded context - Code says `UserRecord` while the business says "applicant" - A term means two different things in two parts of the system - Deciding where one subsystem ends and the next begins - Before any schema, API, or type is written down Not for: choosing the representation of a type once the concept is clear, which is [modeling-with-algebraic-types](../modeling-with-algebraic-types/SKILL.md). ## Core rules 1. **Use the domain's words, unchanged.** If experts say "quote", the type is `Quote`, not `PricingRequestDto`. Words invented by developers are the beginning of two models. 2. **Discover through events.** Ask what happens, in the past tense: "booking confirmed", "payment declined". Events reveal boundaries that nouns hide. 3. **Every workflow is a command in, events out.** Name the trigger, the work, and what the rest of the world learns. That triple is the unit of design. See [design