Arquitectura y límites de los módulos
Una visión técnica de Electron, Angular, SQLite y los casos de uso que coordinan el restaurante.
Plataforma y fuente de verdad#
Restaurante Pro combina un renderer Angular, un proceso principal Electron y persistencia SQLite local. En la operación con varios dispositivos, el host concentra la base y los servicios de negocio. Las terminales y la aplicación móvil acceden a capacidades concretas mediante adaptadores.
| Capa | Responsabilidad | Ejemplo en restaurante |
|---|---|---|
| Domain | Reglas puras e invariantes. | Políticas de precios, asignación de cuentas y distribución de mesas. |
| Application | Casos de uso y coordinación. | Abrir servicio, enviar ronda, cambiar estado de cocina y dividir cuentas. |
| Infrastructure | Persistencia y adaptadores concretos. | Unidad de trabajo TypeORM, cola de impresión y conversión a venta. |
| Interface | Entrada, salida y validación de contratos. | Formularios Angular, validadores, canales IPC y rutas LAN. |
Organización del repositorio#
apps/web/src/app/features: pantallas y estado local por funcionalidad.electron/src/features/restaurant: dominio, casos de uso, infraestructura y validación del restaurante.electron/src/services: servicios de aplicación e integraciones existentes.electron/src/ipcyelectron/src/preload.ts: contratos de escritorio y adaptación.electron/src/server: API LAN, autenticación y publicación de la web móvil.packages/shared/src/features/restaurant: modelos y contratos compartidos.db/sqlite-migrations: evolución versionada del esquema.
Composición de la funcionalidad restaurante#
La composición expone configuración, sesiones, órdenes, cocina, cuentas y consultas. El estado de restaurante tiene entidades propias; no utiliza las sesiones de preventa como sustituto de mesas y comandas. Las rondas se agregan con idempotencia y las transiciones de cocina usan control de versión para detectar cambios concurrentes.
Frontera con caja y ventas#
El cobro convierte una cuenta del restaurante en una venta mediante el motor existente. La venta, la conversión de cuenta, el cierre de servicio y la liberación de mesa se coordinan dentro de una transacción. La asignación de cantidades fraccionarias requerida por cuentas iguales queda restringida a esa conversión interna.
Regla para ampliar el sistema#
Identifica primero la funcionalidad, la capa y el contrato afectado. Conserva la lógica de negocio fuera del renderer, preload y handlers grandes. La UI solicita una intención; los casos de uso la validan y coordinan; la infraestructura persiste o integra. Un cambio transversal debe explicitar cómo afecta los contratos y la recuperación de datos.