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

说明与用途

将餐厅和零售POS的域模型分离简化了每个系统，保持了清晰的不变性，并允许独立演进。

问题

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

结果

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

工作流

• 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.

证据

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.

来源

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

来源

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

来源

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

来源