Domain-Driven Design en la Banca

Domain-Driven Design (DDD) es un enfoque poderoso para el desarrollo de software que alinea la implementación técnica con los dominios del negocio. Sin embargo, aplicar DDD en la banca—especialmente en entornos altamente regulados y con sistemas heredados—está lleno de desafíos.

Los bancos operan bajo restricciones estrictas: cumplimiento normativo, seguridad, gestión de riesgos y sistemas transaccionales complejos. Estas limitaciones hacen que la adopción de DDD sea difícil pero no imposible. Peor aún, algunos bancos creen erróneamente que adoptar estándares como BIAN (Banking Industry Architecture Network) resuelve sus problemas de modelado de dominio—especialmente en Latinoamérica, donde los dominios de servicio eurocéntricos de BIAN suelen chocar con las realidades locales.

En esta publicación, exploraré:

1. Por qué DDD es difícil en la TI bancaria.
2. Los riesgos de implementaciones de DDD a medias.
3. Por qué BIAN no es un atajo para el modelado de dominio en Latinoamérica.
4. Ejemplos reales de éxitos y fracasos.

Los bancos operan en una de las industrias más reguladas. Cada sistema debe cumplir con:

• Basilea III (adecuación de capital).
• Normas AML/LD (anti-lavado de dinero).
• GDPR/Datos Personales (protección de datos).
• Leyes bancarias locales (ej. Dodd-Frank, SOX).

Problema: Las regulaciones suelen dictar el comportamiento del sistema, dificultando el modelado de dominios de negocio puros. Por ejemplo, un "Cliente" en términos de DDD podría dividirse en:

• Cliente-KYC (entidad de cumplimiento).
• Cliente-Transaccional (banca central).
• Cliente-Marketing (CRM).

Esta fragmentación conduce a modelos de dominio anémicos donde la lógica de negocio se filtra a servicios en lugar de residir en las entidades.

La mayoría de los bancos funcionan con:

1. Mainframes (COBOL, CICS)
2. Sistemas monolíticos de banca central (Temenos, Finacle, Flexcube)
3. Flujos de procesamiento por lotes

Ejemplo: Un banco europeo intentó implementar DDD para un nuevo sistema de originación de préstamos, pero tuvo que integrarse con un mainframe de 30 años. El dominio "Préstamo" en el nuevo sistema tuvo que reconciliarse con:

1. Una tabla de préstamos heredada (desnormalizada, actualizada por lotes)
2. Un servicio de evaluación de riesgo (tiempo real, basado en motor de reglas)
3. Un módulo de reporte regulatorio (base de datos separada)

La TI bancaria suele estar dividida en:

1. Banca Central (transacciones, libros contables)
2. Riesgo y Cumplimiento
3. Front Office (Ventas, CRM)
4. Pagos y Tarjetas

Cada silo tiene sus propios modelos de datos, llevando a rupturas del lenguaje ubicuo. Por ejemplo:

1. "Cuenta" significa un asiento contable en Banca Central pero un producto comercial en Banca Minorista.
2. "Transacción" podría significar un pago, una operación bursátil o un ajuste de comisión.

Sin un mapeo claro de contextos, los equipos terminan con sistemas desorganizados y complejos.

Algunos equipos adoptan precipitadamente Agregados, Objetos-Valor y Event Sourcing sin comprender el dominio central.

Caso real: Un banco latinoamericano intentó implementar Event Sourcing para su sistema de pagos pero no consideró:

1. Requisitos de conciliación (los bancos deben cuadrar libros diariamente).
2. Trazas de auditoría regulatorias (los eventos por sí solos no eran suficientes).

Terminaron con dos sistemas: uno con Event Sourcing para procesamiento en tiempo real y otro basado en SQL para reporting. Doble costo de mantenimiento.

Si los contextos no están bien definidos, ocurre:

1. Validaciones duplicadas (verificaciones KYC en múltiples sistemas).
2. Datos inconsistentes (direcciones de clientes en CRM vs. Banca Central).
3. Alto acoplamiento (cambios en un sistema rompen otro).

Ejemplo: Un banco construyó un contexto delimitado de "Onboarding de Clientes" pero no lo segregó adecuadamente de "Scoring Crediticio". Cuando cambiaron las regulaciones, ambos sistemas tuvieron que modificarse - frustrando el propósito del DDD.

BIAN es una arquitectura de referencia diseñada para estandarizar capacidades bancarias (ej. "Onboarding de Clientes", "Procesamiento de Préstamos") en dominios de servicio reutilizables. Busca:

1. Reducir redundancias en software bancario.
2. Mejorar interoperabilidad entre sistemas.
3. Acelerar la transformación digital.

Aunque BIAN provee una taxonomía útil, los bancos latinoamericanos enfrentan desafíos únicos:

• Conflictos con regulaciones locales
  • El dominio "Evaluación de Riesgo de Partes" de BIAN asume normas tipo GDPR, pero los bancos latinoamericanos deben manejar:
    • La LGPD de Brasil + circulares del Banco Central.
    • Reportes UIF de Argentina (más estrictos que FATF).
  • Ejemplo: Un banco mexicano adoptó el dominio "Acuerdo con Cliente" de BIAN pero debió extenderlo para incluir banderas de consentimiento del SAT—un requerimiento local.
• Incompatibilidad con sistemas heredados:
  • BIAN asume servicios modulares, pero los bancos latinoamericanos suelen depender de:
    • Sistemas centrales monolíticos (ej. Cobis, BancoPro).
    • Chequeos de fraude personalizados (ej. base de fraudes del BACEN en Brasil).
  • Caso real: Un banco colombiano mapeó el dominio "Ejecución de Pagos" de BIAN a su motor de pagos heredado... solo para descubrir que no manejaba conversiones de bolívares venezolanos (requerimiento ad-hoc frecuente).
• Matices culturales en productos bancarios:
  • El dominio "Cuenta de Depósito" de BIAN no considera:
  • Las "Poupanças" brasileñas (ahorros ajustados por inflación).
  • Los "Plazos Fijos UVA" argentinos (plazos fijos indexados al dólar).

Falsa esperanza: Algunos bancos creyeron que BIAN:

• Eliminaría el trabajo de modelado de dominio (pero BIAN es un marco, no un modelo de dominio).
• Reemplazaría la lógica de negocio local (pero siempre aparecen reglas locales de impuestos/divisas).

Lección: BIAN es una guía de referencia, no una solución lista para usar.

• Ejemplo: Mapea el dominio "Aprobación de Préstamos" de BIAN a tus reglas de suscripción, pero agrega modelos de riesgo locales (ej. scoring SCR de Brasil).

• El "Acuerdo con Cliente" de BIAN → "Cliente + Cumplimiento Tributario" en LatAm (nuevo contexto)

• Si los pagos transfronterizos son tu diferenciador, modelalos primero—aunque el dominio "Orden de Pago" de BIAN parezca restrictivo.

Los bancos latinoamericanos deben:

• Adaptar BIAN a realidades locales (no asumir correspondencias 1:1).
• Modelar explícitamente particularidades regulatorias (¡son parte del dominio!).
• Evitar tratar BIAN como reemplazo de DDD (es un complemento).

Reflexión final: BIAN es como una navaja suiza—útil, pero aún necesitarás un machete para la jungla latinoamericana.