Proceso Reactivo
Ejemplos
Descripción
Componente que ejecuta una rutina de procesamiento de forma autónoma en cuanto cambian datos que ya residen en el sistema: cuando se da de alta, se edita o se da de baja un registro, el componente lo detecta y reacciona, sin que un usuario lo opere paso a paso ni medie una agenda. Toma el cambio como disparador, aplica una lógica —derivar un dato nuevo, propagar una consecuencia, validar una invariante— y produce un resultado: datos nuevos, datos corregidos o la activación de otro proceso.
El caso canónico: en cuanto aparece un cliente nuevo en la tabla de clientes, créale automáticamente su cuenta de acceso. Nadie agenda esa creación ni la pide a mano; la dispara el propio cambio en los datos. En la industria del software corresponde a tres materializaciones del mismo patrón —el sistema se observa a sí mismo y reacciona—: los database triggers (la base de datos ejecuta lógica ante un INSERT/UPDATE/DELETE), el change data capture (un observador lee el log de transacciones y emite un evento por cada cambio) y los domain events (la aplicación publica un evento de negocio al cambiar su estado, y otro componente lo consume).
Lo que da forma a este componente es el cómo (procesamiento autónomo sobre datos internos, disparado por un cambio en esos datos), no el qué: no fija qué reacción ejecuta, igual que un Mantenedor no fija qué entidad administra. Su pariente cercano, el Proceso Programado, comparte el territorio del procesamiento autónomo interno pero se distingue por el disparador: aquel corre cuando lo manda el reloj; este corre cuando cambian los datos.
Capacidades mandatorias
- Detecta un cambio de estado en datos que ya residen en el sistema (alta, edición o baja de un registro)
- Se dispara de forma autónoma a partir de ese cambio, sin agenda y sin intervención humana en sus pasos
- Ejecuta una lógica de reacción a partir del cambio: derivar un dato, propagar una consecuencia, validar una invariante
- Opera en segundo plano, sin ocupar ni bloquear la interacción del usuario con el sistema
Capacidades adicionales
- Filtro de condición: reacciona solo cuando el cambio cumple cierta condición (por ejemplo, "solo si el cliente nuevo es de tipo empresa"), no ante todo cambio indiscriminadamente
- Encadenamiento: su reacción dispara a su vez otro proceso o notificación, propagando la consecuencia del cambio
- Emisión del resultado: comunica el resultado de forma proactiva (aviso de que la cuenta fue creada, alerta de invariante violada)
- Logging de disparo: registra cada activación (qué cambio la disparó, cuándo, con qué resultado) para auditoría y monitoreo
- Idempotencia y reintentos: garantiza que un mismo cambio no produzca su reacción dos veces, y reintenta si la reacción falla
Delimitaciones
- No reacciona a un evento externo. El cambio que lo dispara nace dentro del sistema (un registro propio que cambió). Si la reacción se gatilla por un aviso que llega desde fuera —una notificación HTTP entrante, un webhook—, eso es entrada externa y corresponde a un Servicio Expuesto, no a un Proceso Reactivo. La distinción es el origen del disparo: interno, no externo.
- No lo dispara el reloj. Si la rutina corre según una agenda (cada noche, cada hora) en vez de ante un cambio puntual de datos, es un Proceso Programado.
- No incorpora datos desde fuera del sistema. Opera sobre los datos que ya están adentro. Si trae datos de una fuente externa, eso es un ETL o un Scraper.
- No involucra decisiones humanas en sus pasos. Si el procesamiento se detiene para que una persona apruebe o rechace, es un Workflow de aprobación.
Flujo de información
Un cambio de estado en datos internos (alta, edición o baja de un registro) que actúa como disparador, detectado por el propio sistema
El resultado de la reacción: datos derivados o corregidos escritos en el sistema, o la activación de otro proceso o notificación
Modalidades
- Disparador de base de datos (database trigger): la propia base de datos ejecuta la lógica ante un INSERT/UPDATE/DELETE sobre una tabla.
- Captura de cambios (change data capture): un observador lee el log de transacciones de la base y emite un evento por cada cambio, que la aplicación consume y procesa.
- Evento de dominio (domain event): la aplicación publica un evento de negocio al cambiar su estado ("cliente dado de alta"), y un manejador suscrito reacciona.
Dependencias típicas
- Repositorio de datos del sistema (Base de Datos) cuyo cambio observa y sobre el que lee y escribe
- Mecanismo de detección de cambios (triggers de BD, conector de captura de cambios, bus de eventos de dominio) que gobierna su disparo
- Reglas de negocio que definen la condición de disparo y la lógica de la reacción
- Sistema de Notificación cuando la reacción se comunica de forma proactiva
Mapeo al Tablero Digital
| Sección | Vínculo | Observación |
|---|---|---|
| Actualización Manual | No | Ningún operador escribe datos paso a paso; la reacción es autónoma. |
| Actualización Automática | No | No incorpora datos desde fuera del sistema; reacciona a cambios en los datos que ya están adentro. |
| Conceptos de Datos | Siempre | Siempre lee la entidad que cambió y/o escribe la que deriva como consecuencia. |
| Salidas por Demanda | No | No responde a una solicitud externa; se dispara solo, por el cambio en los datos. |
| Salidas Automáticas | Opcional | Cuando la reacción se comunica de forma proactiva (aviso de cuenta creada, alerta de invariante violada). |
| Procesos Autónomos | Siempre | Es su esencia: la reacción autónoma que corre sin intervención humana, disparada por un cambio de datos internos. |