ADR-004: Motor de Flujos vs Wizard de Credito
Estado: Aceptada
Fecha: 2026-05-18
Autor: Equipo de Arquitectura
Contexto
La plataforma tiene dos capacidades que podrian solaparse:
- ImagFlow: Motor generico de flujos que orquesta pasos, proveedores y validaciones.
- ImagLend: Producto de credito que necesita un wizard multi-paso para originacion (simulacion, captura de datos, validacion, firma, desembolso).
La pregunta es: el wizard de originacion de credito deberia SER un flujo dentro de ImagFlow, o deberia ser un componente independiente de ImagLend que puede invocar a ImagFlow cuando lo necesite?
Decision
El wizard de credito es un producto especializado de ImagLend. No es un flujo generico. Sin embargo, puede invocar a ImagFlow para pasos especificos como:
- Validacion de identidad (orquestacion de proveedores)
- Firma electronica (integracion con ImagSign via Flow)
- Consulta a bureaus de credito
El wizard mantiene su propio estado, logica de negocio financiera y persistencia multi-sesion. ImagFlow se usa como herramienta de orquestacion cuando se necesita coordinar proveedores externos.
Alternativas Consideradas
| Alternativa | Pros | Contras |
|---|---|---|
| Wizard construido enteramente como flujo en ImagFlow | Reutiliza infraestructura existente | Fuerza logica financiera compleja en un motor generico, pierde flexibilidad |
| Wizard completamente independiente sin integracion con Flow | Maxima autonomia del equipo de Lending | Duplica orquestacion de proveedores, no reutiliza capacidades existentes |
| Wizard independiente que invoca Flow (elegida) | Separacion de concerns, cada sistema hace lo que mejor sabe | Requiere definir contratos claros entre dominios |
Consecuencias
Positivas
- El wizard tiene su propia logica de negocio (simulacion financiera, calculos de tasa, scoring) sin restricciones de un motor generico
- ImagFlow se mantiene generico y reutilizable para cualquier dominio
- Persistencia multi-sesion nativa: el usuario puede abandonar y retomar el proceso
- Clara separacion de responsabilidades entre equipos
Negativas
- Requiere definir y mantener contratos de integracion entre ImagLend e ImagFlow
- Dos sistemas que gestionar en lugar de uno unificado
- El equipo de Lending necesita entender cuando usar Flow vs implementar directamente
Riesgos
- Si los contratos entre dominios no estan bien definidos, la integracion puede volverse fragil
- Podria haber tentacion de duplicar capacidades de Flow dentro del wizard