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
`OutboxEvents`	Eventos diferidos, reintentables o de integracion

Relaciones mas importantes

Que guarda cada entidad clave

Business

Define el marco operativo del negocio:

plan
slug
prefijo de consecutivos
estado y suscripcion

Notas relevantes del modelo actual:

el nombre del negocio puede repetirse entre negocios distintos
el slug debe ser unico porque soporta la reserva publica
el slug se genera en la creacion y luego se trata como identificador estable del negocio

BusinessMembership

Guarda la relacion entre persona y negocio:

rol
estado
indicador de empleado
sede asociada si aplica
deletedAt cuando se elimina logicamente

Una membresia puede ser global si no tiene businessId. La consulta por scope=global se usa para diferenciar esa superficie del contexto de negocio.

El borrado de membresia marca status = DELETED, limpia branchId, desmarca isEmployee, borra el link en Users/{userId}/businessMemberships y puede limpiar reseñas, metricas o cupos relacionados con empleado.

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

OutboxEvent

Guarda efectos diferidos con:

type
aggregateType
aggregateId
status
payload
attempts
availableAt
lastError

Sirve para procesar side effects como WhatsApp, push, sincronizacion de metricas, tasks, limpieza de Storage, cascadas de negocio y sincronizacion con Firebase Auth.

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
`OutboxService`	Creacion, consulta y reencolado de eventos diferidos
`OutboxProcessorService`	Procesamiento por lotes de eventos pendientes o con error
`ExternalDispatchService`	Ejecucion de efectos externos registrados en outbox
`PushNotificationService`	Registro y envio de notificaciones push
`WhatsAppTaskService`	Plantillas y disparo de WhatsApp automatizado
`SchedulingIntegrityService`	Validaciones cruzadas para impedir cambios estructurales que rompan citas activas

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
eventos de outbox

Tambien existen validaciones estructurales que frenan cambios antes de persistirlos, por ejemplo:

impedir cambiar horario de sede si deja citas activas fuera del nuevo horario
impedir eliminar o inactivar servicios con citas activas
impedir agendar con servicios inactivos

Por eso este dominio es especialmente sensible a regresiones.

Resumen​

Colecciones principales​

Relaciones mas importantes​

Que guarda cada entidad clave​

Business​

BusinessMembership​

Booking​

Appointment​

Review​

Metric​

OutboxEvent​

Servicios de aplicacion importantes​

Como trabajan juntos booking y appointment​

Reglas de persistencia relevantes​

Compatibilidades legacy que no deben perderse de vista​

Impacto de los side effects​

Documento relacionado con negocio​