Restaurant POS vs Retail POS: Why I Kept the Domain Models Separate

Description and use

Separating POS domain models for restaurants and retail shops simplifies each system, keeps invariants clear, and allows independent evolution.

Problem

A single universal POS schema can become bloated and obscure domain‑specific workflows when applied to both restaurants and retail shops.

Outcome

Separating domain models simplifies each POS system, keeps invariants readable, and allows independent evolution of restaurant and retail workflows.

Workflow

• Identify domain‑specific entities (tables, guests, kitchen tickets for restaurants; stock, product identifiers for retail).
• Define separate domain models that capture each workflow without extraneous fields.
• Reuse common patterns (auth, receipt, printing, rounding) across both codebases.
• Document modules and scope in public repositories.
• Test boundaries to ensure each product can express its workflow independently.
• Maintain separate repositories to avoid cross‑domain breaking changes.

Evidence

A restaurant order may be attached to a table, have guests and modifiers, produce kitchen tickets, move through preparation states, and depend on reservations or a waitlist.

Source

A retail sale typically has a different relationship to stock, product identifiers, and checkout.

Source

If one model has to represent both, it often grows a forest of nullable fields and conditional rules.

Source

We still reuse patterns that genuinely travel well: authentication/session design, receipt rendering, ESC/POS printing, and careful currency rounding.

Source