Roadmap de implementación
Fases para construir el backend
La implementación avanza por capas verticales que cierran circuitos de negocio reales y reducen riesgo progresivamente.
| Fase | Objetivo | Entrega verificable |
|---|---|---|
| 1. Foundation | Base técnica del servicio | API conectada a PostgreSQL, OpenAPI, logging, healthchecks y manejo de errores |
| 2. IAM | Acceso y permisos | Login, refresh, contexto operativo y RBAC aplicados |
| 3. Catálogo y configuración | Modelo comercial y operativo | Organizations, BUs, productos, precios, descuentos, terminales, mesas, meseros y almacenes |
| 4. POS Runtime | Sesión operativa y caja | Open/close/reconcile session y eventos de caja |
| 5. Orders | Ciclo del ticket | Orden con items, modifiers, descuentos, producción y cierre |
| 6. Payments | Cobro y reversas | Cash, split, refunds, voids, propinas y customer credit |
| 7. Inventory | Stock real y costo | Venta impacta stock y costo vía ledger |
| 8. Purchasing | Abastecimiento | PO, recepción y posteo a inventario |
| 9. AP | Saldos a proveedor | Documentos, pagos y aplicaciones con open_amount consistente |
| 10. Sync | Dedupe y propagación | processed_commands, outbox, replay y cursores |
| 11. Reporting | Visión operativa | Summaries y vistas de operación |
| 12. Hospitality | Extensión de negocio | Rooms y guest folios ligados a órdenes |
Dependencias entre fases
- IAM debe existir antes de cualquier operación sensible.
- Catálogo y configuración deben existir antes de Orders.
- Orders deben existir antes de Payments.
- Orders + Payments condicionan Inventory usable.
- Purchasing antecede a Accounts Payable.
- Sync y Reporting se apoyan en un núcleo operacional ya estable.
El núcleo del dominio está contemplado desde el inicio del proyecto, pero se implementa en orden para cerrar riesgos, validar contratos y evitar rediseños tardíos del motor transaccional.