Phase 2 — Requirements

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.
Core entities and the space that owns each one

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 Documents

Ready to generate your Domain Model?