Backend: datos y servicios

Resumen

El backend usa Firestore como fuente principal de persistencia. Sobre esa base se montan servicios que aplican reglas, sincronizan estados y ejecutan efectos secundarios.

Colecciones principales

Coleccion	Rol en el negocio
Businesses	Tenant principal
Plans	Capacidad operativa por negocio
Branches	Sedes
Services	Catalogo de servicios
Users	Personas del sistema o clientes
BusinessMemberships	Vínculo usuario-negocio
Roles	Grupos de permisos
Modules	Dominios funcionales
Permissions	Permisos base
Bookings	Reserva comercial
Appointments	Cita operativa
Reviews	Calificaciones
Metrics	Agregados del negocio
DeletedUsers	Trazabilidad de usuarios eliminados

Relaciones mas importantes

Que guarda cada entidad clave

Business

Define el marco operativo del negocio:

• plan
• slug
• prefijo de consecutivos
• estado y suscripcion

BusinessMembership

Guarda la relacion entre persona y negocio:

• rol
• estado
• indicador de empleado
• sede asociada si aplica

Booking

Guarda la parte comercial:

• cliente
• sede
• citas asociadas
• total
• abono
• metodo y estado de pago

Appointment

Guarda la parte operativa:

• fecha
• hora inicio y fin
• servicio
• empleado
• estado

Review

Registra reputacion posterior al servicio y puede apuntar a:

• empleado
• sede

Metric

Guarda agregados por:

• negocio
• sede
• empleado

Servicios de aplicacion importantes

Servicio	Responsabilidad principal
BusinessService	Alta, cambio de estado y borrado de negocio
BusinessMembershipService	Roles, sucursales, empleados y reglas de membresia
BookingService	Creacion, edicion, pagos y sincronizacion del booking
AppointmentService	Agenda, reprogramacion y estados de citas
ReviewService	Alta y limpieza de reseñas
MetricService	Recalculo y consulta de metricas
PushNotificationService	Registro y envio de notificaciones push
WhatsAppTaskService	Plantillas y disparo de WhatsApp automatizado

Como trabajan juntos booking y appointment

La regla general es:

• el booking agrupa la transaccion
• la appointment ejecuta la agenda

Eso obliga al backend a sincronizar:

• estados
• totalAmount
• paidAmount
• paymentStatus
• tasks programadas
• metricas
• reviews asociadas

Reglas de persistencia relevantes

• se usan timestamps como createdAt, updatedAt, cancelledAt y deletedAt
• existe soft delete en varias entidades
• FirestoreService normaliza timestamps al responder

Compatibilidades legacy que no deben perderse de vista

• existen citas antiguas con services[] en lugar de serviceId/startTime/endTime
• algunas referencias de userId en memberships pueden venir por id o por document
• existen nombres heredados como BUSSINESS y prefijos de storage bussinesses/

Impacto de los side effects

Cuando cambia una reserva o cita, los servicios pueden tener que tocar varias piezas:

• agenda
• pagos
• metricas
• reseñas
• notificaciones
• tasks diferidas

Por eso este dominio es especialmente sensible a regresiones.

Documento relacionado con negocio

• Ciclo de vida de bookings
• Reglas de negocio
• Integraciones y operacion