State Modeling
What changes over time — order status, cart contents, inventory, payment status — and the state machines that fall out of asking.
Entities say what exists; state says what about them changes. Order status, cart contents, stock levels and payment status all change, each on a different trigger, and each one is a place where the system must know "the current value" — which is where most bugs live.
For every piece of state there is a choice: keep the current value, keep the history, or both. Stock is a number that is overwritten and a history that is appended; the choice depends on who will ask "why?", and getting it wrong is cheap to fix early and expensive later.
When a piece of state has a small set of named values, the values are half the model; the other half is which transitions are allowed and who causes them. Order CREATED → PAID → SHIPPED → DELIVERED, with CANCELLED and REFUNDED as exits, is discovered by asking "from here, what can happen?" until nothing new appears.
PENDING → PAID → FULFILLED, with CANCELLED and REFUNDED added later. Which transitions are legal, who triggers each, and in what order to build them so that the store works before the machine is complete — the state module applied end to end on the capstone's order.
Paid twice, shipped before paid, refunded with no payment: some combinations of state must not merely be rejected at runtime but be impossible to write down. Finding them is a discovery move — ask which combinations of fields would be a lie — and where to enforce each is a decision, not a doctrine.