Saltar a contenido

Modelo de dominio

Entidades y relaciones aprobadas en el discovery del proyecto (Q1, 2026-09-03). Esta página describe el modelo conceptual; el esquema físico exacto —columnas, tipos, constraints— vive en Base de datos.

Entidades

TipoCliente

Tipo de cuenta del medio de pago que puede recibir un beneficio.

  • codigo (único, ej. DINI_NEGOCIOS)
  • nombre
  • paymentMethodId (obligatorio, único; ej. 990, 991) — el identificador que usa el autorizador
  • activo

Sucursal

Catálogo propio de sucursales del comercio.

  • codigoExterno (único; el que envía el gateway en branchId)
  • nombre
  • activa

Beneficio

Regla que produce un porcentaje de descuento para uno o más tipos de cliente.

  • nombre, descripcion
  • porcentaje (0 < p ≤ 100)
  • vigenciaDesde, vigenciaHasta (fechas)
  • diasSemana (conjunto; vacío = todos)
  • horaDesde, horaHasta (franja; vacía = todo el día)
  • montoMinimo (opcional)
  • topeDescuento (opcional; monto máximo de descuento)
  • prioridad (entero; menor = gana)
  • tiposFactura permitidos (conjunto; vacío = todos)
  • codigosExtra permitidos (conjunto de texto libre; vacío = todos) — filtra contra invoice.extraCustomerTypeId del request; sin catálogo propio en v1
  • tiposCliente (N:M, al menos uno)
  • sucursales (N:M; vacío = todas)
  • estado (ACTIVO, INACTIVO)

Usuario

  • usuario (único), hashPassword (BCrypt), rol (ADMIN | OPERADOR), activo

Consulta

Registro de auditoría de cada petición de resolución. No es la transacción de pago: BeneficiosCenter no conoce el resultado del pago; se cruza con la Trx del gateway por requestId.

  • requestId (del gateway)
  • recibidaEn, latenciaMs
  • request (JSON completo)
  • response (JSON completo)
  • evaluaciones: por cada beneficio candidato, aplico y motivo cuando no aplicó
  • resultado (OK, SIN_BENEFICIOS, ERROR_VALIDACION, NO_AUTENTICADA, ERROR_INTERNO)

Relaciones

erDiagram
    TIPO_CLIENTE ||--o{ BENEFICIO_TIPO_CLIENTE : "N:M"
    BENEFICIO ||--o{ BENEFICIO_TIPO_CLIENTE : "N:M"
    SUCURSAL ||--o{ BENEFICIO_SUCURSAL : "N:M"
    BENEFICIO ||--o{ BENEFICIO_SUCURSAL : "N:M"
    BENEFICIO ||--o{ BENEFICIO_DIA_SEMANA : "1:N"
    BENEFICIO ||--o{ BENEFICIO_TIPO_FACTURA : "1:N"
    BENEFICIO ||--o{ BENEFICIO_CODIGO_EXTRA : "1:N"
    CONSULTA ||--o{ CONSULTA_BENEFICIO : "1:N (beneficios ganadores)"
    BENEFICIO ||--o{ CONSULTA_BENEFICIO : "1:N"

    TIPO_CLIENTE {
        string codigo PK
        string nombre
        string paymentMethodId UK
        bool activo
    }
    SUCURSAL {
        string codigoExterno PK
        string nombre
        bool activa
    }
    BENEFICIO {
        string nombre
        string descripcion
        decimal porcentaje
        date vigenciaDesde
        date vigenciaHasta
        time horaDesde
        time horaHasta
        decimal montoMinimo
        decimal topeDescuento
        int prioridad
        string estado
    }
    USUARIO {
        string usuario PK
        string hashPassword
        string rol
        bool activo
    }
    CONSULTA {
        string requestId
        datetime recibidaEn
        int latenciaMs
        string request
        string response
        string evaluaciones
        string resultado
    }

Evaluacion (aplicó / motivo por cada beneficio candidato) está embebida en Consulta, no es una entidad independiente: viaja como parte del JSON de evaluaciones de esa consulta.

Invariantes del modelo

Se formalizan como reglas duras en Invariantes:

  • En una respuesta hay a lo sumo un beneficio por TipoCliente (INV-D01).
  • Los beneficios nunca se acumulan (INV-D02).
  • paymentMethodId es único entre TipoCliente (INV-D04).

Dónde sigue