schema-designlisted

# Schema Design Design the data model that sits beneath the API and beside the domain language. `architecture` picks the datastore type; `domain-modeling` sharpens the vocabulary; this skill designs the actual shape of the data — entities, relationships, indexes, constraints, and how the model scales. A schema designed reactively (added-to-as-features-arrive) becomes a performance and correctness liability that is expensive to fix later. ## When to use - Designing entities and relationships for a new feature or bounded context - Choosing normalization level, indexing strategy, or partitioning for a new model - Reviewing a proposed schema for correctness, performance, or future evolution - Triggers on "data model", "schema design", "database design", "ER model", "数据模型", "表结构设计", "数据库设计" > **Scope:** assumes a relational datastore (Postgres/MySQL/SQLite). For document stores > (MongoDB), key-value (DynamoDB), or graph stores, the embedding-vs-referencing and > sharding decisions differ — use `architecture` for datastore selection, then adapt these > patterns. **Not for:** choosing the datastore type (use `architecture`); ubiquitous-language glossary (use `domain-modeling`); API request/response shapes (use `api-design`); changing an existing schema in production (use `deprecation-migration`). ## Steps ### 1. Map entities and relationships Start from the domain model (`domain-modeling` output / CONTEXT.md) and translate nouns into entities, verbs into relationships. For