Domain Model
The skeleton every database, API, and UI decision hangs from
2 min read · Document 6 of 30
What is this document?
The Domain Model names every core entity in your product, what each one means, which space owns it, and how entities relate — with cardinalities. It is the shared vocabulary for the database, the API and the interface.
Terms are defined once and reused everywhere, so “customer”, “account” and “user” never drift into three meanings.
Why does it matter?
- When AI tools invent entities on the fly, you end up with user, users, customer and account all meaning slightly different things across modules.
- Ownership labels stop two spaces from writing the same data.
- Relationships decided up front avoid painful schema migrations later.
What's inside?
- Entities — Name, meaning, owning space and lifecycle states.
- Relationships — Cardinality and direction for every link.
- Glossary — One definition per term, used across all documents.
How CREAH generates it
CREAH builds this document from your Stage 0 answers and interview. Questions that shape it include:
- Can one customer belong to more than one organisation?
- Who is allowed to create, edit and delete each record?
- Which records must be kept after an account is deleted?
Example excerpt
## Core Entities
**Project** (owned by: User Space)
belongs to one User or Organization
has many Spaces · has one Payment · has many Documents
**Space** (owned by: Platform Core)
belongs to one Project · has many DocumentsRelated documents
Database Specification
Every table, every relationship, every constraint — resolved before the first migration
Phase 3API Specification
Every endpoint, typed and contracted, before the AI writes a single route handler
Phase 2User Journey Specification
Walk the AI through your product before it writes a single component