Domain-Driven Design en Banca

Los bancos no son solo instituciones financieras, son ecosistemas complejos de regulaciones, sistemas heredados y expectativas de clientes en rápida evolución. Los enfoques tradicionales de TI a menudo colapsan ante esta complejidad. El Diseño Orientado al Dominio (DDD) ofrece un camino al alinear la tecnología con la realidad del negocio. ¿Pero por dónde empezar? Aquí explicamos cómo dar los primeros pasos sin intentar abarcar demasiado.

• Domar la Complejidad: Regulaciones (AML, KYC), banca multicanal y sistemas heredados crean complejidad inherente. DDD proporciona herramientas para descomponerla.
• Romper Silos: DDD fuerza la colaboración entre expertos de negocio (oficiales de riesgo, asesores de préstamos) y equipos técnicos.
• Modernizar Gradualmente: DDD permite crear servicios modernos alrededor de núcleos heredados (ej: pagos, onboarding).

¡Evita empezar con banca central o reportes regulatorios! Apunta a dominios donde:

• La complejidad es alta pero el riesgo está contenido: Ej: Onboarding de Clientes, Originación de Préstamos o Asesoría de Gestión Patrimonial.
• Los expertos de negocio están comprometidos: Dueños de producto apasionados = combustible para el éxito.
• Los resultados son medibles: Ej: "Reducir tiempo de onboarding de 10 días a 2".

• Objetivo: Construir un lenguaje compartido (Lenguaje Ubicuo).
• Cómo:
  • Reúne expertos reales del dominio (no solo gerentes): Ej: suscriptor de préstamos experimentado + oficial de cumplimiento + líder técnico.
  • Mapea procesos clave (Event Storming): Usa notas adhesivas (físicas o virtuales). Enfócate en:
    • Eventos de Dominio: Ej: IdentidadClienteVerificada, RiesgoCrediticioEvaluado, SolicitudPréstamoRechazada.
    • Comandos: Ej: VerificarDirecciónCliente, CalcularRatioDeuda-Ingresos.
  • Consejo Bancario: Empieza con un caso ideal (ej: "Préstamo Minorista Simple"), luego añade excepciones (ej: "Retención KYC Transfronteriza").

• Qué es: Un límite lógico donde aplica un modelo de dominio específico (ej: Onboarding de Clientes ≠ Detección de Fraude).
• Cómo empezar:
  • Identifica un subdominio cohesivo en tu taller (ej: Verificación de Identidad dentro de Onboarding).
  • Define límites explícitos: "Dentro de este BC, 'Cliente' significa datos de identidad verificada. Fuera, puede significar preferencias de marketing".
• Realidad Bancaria: Tu BC probablemente necesitará integrarse con sistemas heredados (ej: verificación KYC en mainframe). Planea adaptadores temprano.

• Qué: Un límite transaccional que protege reglas de negocio (ej: agregado SolicitudPréstamo que hace cumplir reglas de "borrador vs. enviado").
• Empieza pequeño:
  • Elige 1-2 agregados críticos por BC (ej: en Pagos: OrdenPago + BalanceCuenta).
  • Crítico en Banca: Haz cumplir invariantes como "El pago debe reservar fondos atómicamente" o "La verificación AML debe preceder a la ejecución".

• Problema: Los BCs necesitarán comunicarse (ej: Onboarding → Banca Central).
• Empieza simple:
  • Capa Anticorrupción (ACL): Protege tu nuevo BC del caos de sistemas heredados. ¡Envuelve esa API de mainframe!
  • Publica Eventos de Dominio: Ej: OnboardingCompletado → dispara CrearClienteBancaCentral en otro sistema.
• Evita: Transacciones distribuidas entre BCs (el veneno de la banca).

• Ignorar Restricciones Regulatorias: Modela regulaciones explícitamente (ej: objeto ReglaCumplimientoAML).
• Sobre-ingenería: No modeles todo el banco. Empieza con un BC e itera.
• Subestimar Integración con Sistemas Heredados: Planea sincronización de datos temprano.
• DDD Impulsado por Tecnología: DDD trata sobre alineamiento con el negocio. Si los expertos de negocio no están en la sala, detente.

1. Soluciona un Punto de Dolor: Usa DDD para optimizar procesos problemáticos (ej: reducir pasos de onboarding).
2. Visualiza tu Dominio: Comparte mapas de Event Storming con liderazgo - genera compromiso.
3. Mide: Haz seguimiento al tiempo de ciclo antes/después en tu dominio piloto.

DDD en banca no se trata de una transformación de la noche a la mañana. Se trata de incrementalismo estratégico: identificar dominios donde la complejidad más duele y alinear tecnología con realidad del negocio. Empieza pequeño, involucra a tus expertos y deja que el dominio guíe. Tus sistemas heredados no desaparecerán, pero DDD te permite construir islas de claridad en el caos.

Siguiente Paso: Realiza una sesión de 2 horas de Event Storming sobre un proceso bancario problemático. Solo el mapa revelará más que cualquier documento.