Data Discovery
From "customer places an order containing products" to Customer, Order, OrderItem, Product. Entities from plain English, what must persist, and snapshots against references.
"Customer places an order containing products" is already a data model: Customer, Order, OrderItem, Product. Entities are the nouns, relationships are the verbs, and the hidden entity is the one the sentence needs but does not name.
A requirement is a source of entities only if it is read for them. The rule is a noun the system must remember; the traps are nouns that are really attributes, attributes that are really entities, and the entity you only find by asking "one or many?".
"Users can create projects and invite members" hides User, Project, Membership and Invitation — two of which are verbs. The move is to read requirements as data until a first schema falls out, then hand the schema to Database Engineering to make it correct.
Not everything the system knows must survive a restart. Orders must; a cart may; a product's "in stock" badge is recomputed. Sorting data into must-persist, may-persist and recompute is what keeps the schema small and the losses acceptable.
The price the customer paid lives on OrderItem, not on Product. Whenever a fact was true at a moment and the thing it refers to can change, the fact is a snapshot; a reference is right only when the current value is the one wanted.