Cuando el negocio no es el tuyo: cómo entender el dominio para rediseñar un sistema de facturación con event-driven

Llegué a ese proyecto sin saber exactamente en qué me estaba metiendo.

El sistema tenía problemas de facturación: cargos que no se aplicaban, cargos duplicados, y nadie con certeza absoluta de cuándo debía procesarse uno. El equipo de producto tenía documentados más de 10 escenarios. Y yo, que venía de otro país, tenía que entender primero cómo funcionaba ese negocio con sus propias reglas, sus propios términos y su propia lógica.

Esa combinación — un sistema roto, un dominio que no era el mío y presión por resolverlo — es exactamente el tipo de situación donde es tentador ir directo al código. Por suerte, no lo hice.

El síntoma: una lista interminable de “cuándo facturar”

Cuando llegué al sistema, lo primero que vi fue la lista de escenarios que el equipo manejaba:

• El cliente tiene una deuda activa sin pago
• El cliente tiene una deuda activa con pago
• El cliente tiene una deuda activa con pago y es fin de mes
• El cliente tiene una deuda activa sin pago y es fin de mes
• ... y múltiples combinaciones de los anteriores

Antes — lógica basada en combinaciones de estados:

El equipo técnico los había modelado tal como el equipo de producto los había descrito. Y el equipo de producto los había descrito tal como los había visto ocurrir en el sistema. El problema es que eso no es el negocio — son los síntomas del negocio.

Hay una diferencia importante entre “esto es lo que pasa en el sistema” y “esto es lo que significa para el cliente”. Cuando modelas los primeros, terminas con lógica frágil que se rompe ante cualquier caso borde. Cuando modelas los segundos, encuentras los patrones reales.

Lo que teníamos era un sistema que reaccionaba a estados del sistema. Lo que necesitábamos era un sistema que reaccionara a eventos del negocio.

El proceso: aprender el dominio antes de tocar el código

Tomé la decisión de no proponer ninguna solución técnica hasta entender cuándo debía procesarse un cargo de verdad. Esto implicó sesiones con el equipo de producto — no para que me explicaran los escenarios del sistema, sino para que me explicaran el negocio: ¿qué cambia en la vida del cliente para que se genere una obligación?

Esa distinción cambió completamente la conversación. Empezamos a hablar en términos del ciclo de vida de una deuda, no de combinaciones de estados. Y cuando haces eso, la lista interminable de escenarios empieza a colapsar. Muchos de ellos eran variantes del mismo momento de negocio, disparados desde diferentes partes del código por razones históricas, no por razones lógicas.

Al final, todo el ruido se redujo a 4 eventos de negocio reales:

1. Adquisición del préstamo — el cliente adquiere una deuda
2. Pago parcial del usuario — el cliente realiza un abono
3. Fin de mes con pagos — cierre del periodo, se consolidan los movimientos
4. Liquidación de la deuda — el cliente salda completamente

Cualquier escenario de la lista original era consecuencia de uno de estos cuatro. No había un quinto evento. Solo había complejidad accidental acumulada con el tiempo.

La solución técnica: AWS EventBridge como bus central

Con el modelo de negocio claro, la implementación se volvió relativamente directa. Usamos AWS EventBridge como bus de eventos central.

Después — 4 eventos de negocio claros:

Cada dominio publica eventos de negocio cuando algo relevante ocurre. El servicio de facturación escucha únicamente los 4 eventos que importan y ejecuta la lógica correspondiente.

Una ventaja importante que ya venía del diseño del sistema: cada evento traía un identificador único derivado de los movimientos contables. Esto eliminó de raíz el problema de duplicados sin necesidad de lógica adicional — la trazabilidad ya estaba en el dato.

Dead letter queue para fallos. Los eventos que no se procesan correctamente van a una DLQ para revisión, en lugar de perderse silenciosamente como pasaba antes.

Logs de auditoría por evento. Cada evento procesado deja un registro con su ID, timestamp y resultado. Por primera vez, el equipo tenía visibilidad completa del ciclo de facturación.

El resultado

El cambio fue inmediato. Los cargos duplicados desaparecieron. Los cargos perdidos también. El equipo de producto pasó de manejar excepciones manualmente cada semana a tener un sistema que, cuando falla, falla de forma visible y recuperable.

Pero lo que más me quedó no fue el resultado técnico. Fue lo que aprendí sobre cómo enfrentar sistemas en dominios que no conoces.

La lección de arquitectura

Hay un concepto útil para este tipo de situaciones: la distinción entre complejidad esencial y complejidad accidental.

La complejidad esencial viene del negocio. Si la facturación de préstamos es complicada, es porque el negocio tiene reglas complicadas. No puedes eliminarla, solo modelarla bien.

La complejidad accidental es la que nosotros mismos creamos: código que creció sin diseño, escenarios modelados como síntomas, lógica duplicada por urgencia. Esta sí puedes eliminarla — pero solo si primero entiendes cuál es cuál.

Los 10+ escenarios que teníamos eran mayormente complejidad accidental. Los 4 eventos que encontramos eran la complejidad esencial del negocio. El trabajo fue separar una de la otra.

Como gente de tech, a veces caemos en la trampa de modelar lo que vemos en lugar de modelar lo que es. Vemos muchos casos, muchos estados, muchas combinaciones — y construimos un sistema para cada uno. Pero casi siempre, detrás de esa superficie hay un modelo más simple esperando ser descubierto.

La próxima vez que enfrentes un sistema “complejo”, antes de buscar la solución técnica, hazte esta pregunta: ¿estoy mirando el negocio o estoy mirando los síntomas del negocio?

¿Te ha tocado simplificar un dominio que parecía irreduciblemente complejo? Me encantaría leer cómo lo abordaste en los comentarios.