domain-modellerlisted

# Domain Modeller Model-first design skill. Maps entities, relationships, and boundaries before code. Prioritises understanding the domain over jumping to implementation. Outputs conceptual models as Mermaid diagrams or Cypher-compatible graph structures. --- ## When This Skill Applies Use this skill when: - Designing a new feature, module, or system - The conversation shifts from "what should we build" to "how should we build it" - Entities and their relationships are unclear or undocumented - Multiple data stores are involved (polyglot persistence decisions) - A feature touches multiple parts of the system - The user says "I'm not sure how this fits together" - Before writing any significant new code --- ## Core Principle **Understand the domain before solving it.** Sophistication is not clever code — it's depth of understanding. A well-modelled domain makes implementation obvious. A poorly modelled domain makes every line of code a fight. The sequence is always: **Model → Design → Build** --- ## The Modelling Process ### Step 1: Identify Entities What are the nouns? What things exist in this domain? **Questions to ask**: - What are the core objects/concepts? - Which of these are primary (exist independently) vs secondary (exist in relation to something else)? - What's the lifecycle of each entity? - Are there implicit entities hiding behind properties? ``` Example: "Users can enrol on courses and track progress" Entities: User, Course, Enrolment, Progress H