Mejores prácticas de desarrollo
Las siguientes mejores prácticas se publican para ayudar a tomar buenas decisiones de ingeniería sobre el diseño de tus flows y la implementación de aplicaciones IPF. Cubren la descomposición de tu solución en varios flows, la reutilización, cómo aprovechar mejor las funcionalidades de flo-lang y más.
Simplificar el alcance de los flows de orquestación
Los recorridos de pago de extremo a extremo normalmente se dividen en 2 o más flows de orquestación IPF discretos, cada uno representando piezas bien delimitadas de funcionalidad específica del dominio.
Justificación - Dividir los flows por áreas de funcionalidad específicas del dominio y reducir la complejidad y el alcance de los flows los hace:
-
Más simples de entender para otros BAs e ingenieros
-
Más fáciles de mantener, ya que el impacto de los cambios es menor
-
Más fáciles de probar, ya que los flows pueden probarse de forma aislada
Implicaciones - Los flows que componen un recorrido de pago deben desglosarse en áreas funcionales discretas. Estas típicamente pueden incluir:
-
Inicio del pago (gestión de órdenes)
-
Ejecución del pago
-
Compensación y liquidación
Consulta Ejemplo de diseño de flow
Separar el procesamiento para diferentes tipos de pago
Los tipos de pago funcionalmente diferentes deben tener flows de orquestación distintos; por ejemplo, pagos entrantes y salientes.
Justificación - Diferentes tipos de pago, por ejemplo mensajes entrantes PACS.008 comparados con mensajes salientes PAIN.001, son funcionalmente distintos desde la perspectiva del procesamiento de pagos y, por lo tanto, requerirán flows de orquestación diferentes.
Implicaciones - Los flows de orquestación de pagos deben dividirse por distintos tipos de procesamiento:
-
Pagos entrantes vs. salientes
-
Diferentes tipos de mensajes de pago: PAIN.001, PACS.003, PACS.008, etc.
-
Pagos en lote vs. individuales
-
Pagos nacionales vs. internacionales
Diferentes flows consumirán datos de diferentes colas de mensajes, lo que permite priorizar distintos tipos de pagos según los requisitos.
Cabe señalar que los flows de inicio normalmente son agnósticos al CSM/Scheme.
Reutilizar componentes de los flows de pago cuando sea posible
Aunque diferentes tipos de pago pueden tener flows de orquestación distintos, estos flows pueden y deben contener componentes reutilizables compartidos entre ellos (p. ej., componentes/bibliotecas compartidas, subflows).
Justificación - El procesamiento de diferentes tipos de pago probablemente contenga mucha comúnalidad:
-
Comprobación de sanciones
-
Detección de duplicados
-
Integraciones comunes con dominios externos
Implicaciones - IPF fomenta la reutilización de componentes de flows mediante la creación de bibliotecas de flows reutilizables. Estas bibliotecas pueden reutilizarse en múltiples flows.
Consulta estas páginas para ejemplos y guías Crear bibliotecas reutilizables y Subflows
Gestionar notificaciones desde los flows de orquestación
Es posible enviar notificaciones directamente desde los flows de IPF; sin embargo, IPF tiene otros mecanismos para enviar notificaciones que pueden ser más eficientes que añadir complejidad extra a los flows.
Justificación - IPF tiene múltiples opciones para permitir que los clientes reciban notificaciones
-
Añadir acciones específicas al DSL del flow para enviar notificaciones cuando se alcancen ciertos estados
-
Consumir dominios/eventos desde el tema genérico Processing Data
-
Usar el servicio de estado de pagos Notification Service
Implicaciones - Añadir notificaciones a un flow añade complejidad y latencia a ese flow. Esta puede ser la mejor aproximación cuando la notificación requiere lógica compleja y usa datos del contexto de procesamiento del flow.
No obstante, cuando las notificaciones son simples y frecuentes (es decir, enviar una notificación cada vez que se alcanza un nuevo estado), considera usar IPF processing data o el servicio de notificaciones de pagos.
Evitar demasiadas decisiones secuenciadas dentro de los flows
Un número excesivo de estados de decisión dentro de un flow sugiere que se están cubriendo demasiados casos de uso dispares con un solo flow, además de causar un número exponencialmente mayor de posibles rutas a través del flow.
Justificación - Si hay un gran número de decisiones en un flow de procesamiento, puede ser porque el flow está intentando cubrir demasiados casos de negocio y, por tanto, tiene demasiada complejidad.
Además, IPF utiliza un marco BDD para probar los flows como parte del proceso de build; durante estas pruebas, se prueba cada ruta posible a través de un flow. Las decisiones secuenciales pueden aumentar exponencialmente el número de rutas posibles, haciendo que los BDD sean inmanejables.
Implicaciones - Divide los flows grandes, con múltiples decisiones, en flows más pequeños y coloca las decisiones sobre qué flow llamar en el flow precedente.
Por ejemplo, crea flows de ejecución adicionales y coloca la lógica de decisión sobre cuál llamar en el flow de inicio.
Gestión de datos dentro de los flows
Al interactuar con dominios y funciones externas, intenta usar el conjunto mínimo de datos requerido para esa interacción en lugar de enviar cargas de datos grandes innecesariamente.
Justificación - Los datos que se envían a dominios externos y que se usan en otro procesamiento del flow se almacenan en domain events y system events. Estos eventos luego se almacenan en la base de datos y se transmiten a otros sistemas (p. ej., al ODS vía IPF processing data).