domain-modellisted

# Domain model The user describes how their business actually works. You come back with the concepts hiding in that description — and every one of them traces to something they said. An invented model is worse than none: it's fluent, confident, wrong, and in six months it's in the code under a name nobody in the business recognizes. Five things come out, and nothing else: | | | | --- | --- | | **Language** | The words the business uses, meaning what the business means. | | **Flow** | The events, in order. Past tense — something became true. | | **Rules** | Whenever X happens, we do Y. The branches and the exceptions. | | **Aggregates** | Whatever protects a rule and emits those events. | | **Contexts** | Where a word stops meaning one thing and starts meaning another. | No entities-versus-value-objects, no repositories, no schema, no class diagram — those are implementation, and this is what implementation gets checked against. Don't read code either. The code already chose names, and the ones it chose are the loudest thing in the room; read them and they end up in the model, at which point the model can only tell you what the code already says. ## Workflow 1. Capture the process in the user's words. 2. Harvest the language before interpreting any of it. 3. Interview in rounds, leading with a proposed model. 4. Fill in the template and paste it whole for review — the only gate, and nothing reaches disk the user hasn't read in a message first. 5. Write to `docs/domains/<