Saber Pro Diseño de Software: La regla del 40 % vive en tres lugares y con dos umbrales distintos

La regla del 40 % vive en tres lugares y con dos umbrales distintos

Un banco de consumo mantiene la regla «un cliente no puede tener más de 3 créditos activos y la suma de sus cuotas no puede exceder el 40 % del ingreso declarado». Esa regla vive en tres lugares: un controlador REST en Java, un job batch en PL/SQL y un script de migración de datos. Las versiones divergieron: el controlador valida 40 %, el batch valida 35 % porque riesgos lo ajustó en 2021 y nunca se documentó, y el script no valida nada. El trimestre pasado, 212 solicitudes aprobadas por el batch fueron rechazadas después por el controlador, con 40 quejas formales y 3 sanciones del regulador. La entidad SolicitudCredito es un POJO con 40 campos y setters públicos; toda la lógica está en servicios de 900 líneas. El arquitecto propone un motor de reglas Drools en un microservicio nuevo, con un plazo de 6 meses; nadie del equipo ha usado Drools.

1. ¿Dónde debería vivir la invariante de capacidad de endeudamiento? Compare dejarla en los servicios actuales frente a modelarla en el dominio.

Read the worked answer

Por qué la ubicación actual falla. Con un modelo anémico, la regla no tiene un lugar canónico: cada capa la reimplementa y la reimplementación deriva. El resultado observable son 212 aprobaciones contradictorias. El problema no es la falta de un motor, es la ausencia de una única definición ejecutable.

Qué modelar en el dominio.

Objetos de valor: Dinero (monto + moneda, sin primitivos sueltos), IngresoMensual, PorcentajeEndeudamiento, Periodo. Un PorcentajeEndeudamiento solo se construye válido; comparar contra 0,40 deja de ser un número mágico esparcido.
Comportamiento: SolicitudCredito.evaluarCapacidad(ingreso, cuotasVigentes) devuelve un resultado explícito (Aprobada, RechazadaConMotivo) en vez de un booleano. El motivo es lo que permite explicar el rechazo al cliente y al regulador.
Política explícita: PoliticaCapacidadDePago con el umbral como dato configurable y versionado, no como literal en el código.

Matiz importante. La regla «máximo 3 créditos activos» cruza agregados: un Credito individual no puede verificarla solo. Se resuelve con un servicio de dominio o política que consulte el estado consolidado del cliente, aceptando que la verificación final requiere una lectura consistente al momento de aprobar. No se debe forzar dentro del agregado Credito.

Ventaja frente a los servicios actuales. Una sola definición, probada con casos límite (exactamente 40 %, ingreso cero, cuotas en mora), y reutilizable por REST, batch y migración.

2. Evalúe la propuesta del arquitecto de usar Drools en un microservicio nuevo. ¿Qué problema resuelve y qué problema no? ¿Qué alternativa recomendaría?

Read the worked answer

Qué sí resuelve Drools. Externalizar reglas que cambian con frecuencia y que analistas de negocio necesitan leer o autorizar, con trazabilidad de versiones y capacidad de explicar por qué se disparó una regla. Ese es un beneficio real en dominios regulados.

Qué no resuelve.

No corrige el modelo anémico: si la entidad sigue siendo un POJO con setters, las reglas seguirán operando sobre datos sueltos y el dominio seguirá sin proteger sus invariantes.
No elimina la duplicación por sí solo: si el batch sigue con su PL/SQL, habrá dos motores de decisión.
Añade riesgo: 6 meses con un equipo que no conoce Drools, más un salto de red en la ruta crítica de aprobación de crédito.

Criterios de comparación. Frecuencia de cambio de las reglas, quién las cambia, criticidad de la latencia, competencias del equipo y costo operativo del nuevo componente.

Alternativa recomendada. Extraer un módulo de dominio capacidad-de-pago dentro del mismo despliegue, con la política parametrizada, pruebas de casos límite y una API interna que consuman REST, batch y migración. Es la opción de menor riesgo y ya elimina la causa raíz (tres implementaciones). Reevaluar Drools si en el siguiente año las reglas cambian más de una vez al mes y el negocio exige editarlas sin despliegue; en ese momento se introduce el motor detrás de la misma interfaz, sin reescribir el dominio.

3. Existe una discrepancia entre el 35 % del batch y el 40 % del controlador. ¿Cómo la resuelve y cómo evita que reaparezca?

Read the worked answer

Primero, tratarla como decisión de negocio, no técnica. La pregunta correcta no es «cuál número es el correcto» sino «cuál es la intención vigente y si los dos umbrales cumplen funciones distintas». Es plausible que el 35 % fuera un prefiltro deliberadamente conservador del batch para reducir carga del controlador; también es plausible que sea un error de 2021. Sin esa respuesta, cualquier unificación puede romper una intención válida.

Proceso de resolución.

Escalar a riesgos y cumplimiento con la evidencia: 212 aprobaciones contradictorias, 40 quejas, 3 sanciones.
Documentar la decisión en un registro de decisiones de arquitectura con fecha, responsable, fundamento normativo y vigencia.
Si ambos umbrales son legítimos, nombrarlos y modelarlos por separado (prefiltroBatch = 0,35, politicaAprobacion = 0,40) con una prueba que verifique la relación entre ambos. Si no, eliminar uno.

Prevención de recurrencia.

Un único punto de verdad parametrizado; el batch invoca la misma política en lugar de reimplementarla en PL/SQL.
Pruebas de contrato que comparen el resultado del batch y del controlador para una misma solicitud: si divergen, la compilación falla.
Prohibir umbrales literales en revisión de código (regla de lint o test de arquitectura).
Registro de cambios de parámetros con autor y justificación, auditable ante el regulador.