Esta es una visión conceptual de alto nivel de la arquitectura del motor de reglas de negocio. Está por encima del código real. Si estás construyendo un motor de reglas de negocio – es muy probable que encuentres este texto útil.

Una vez, construí un motor de reglas de negocio que permitía la automatización del negocio para las pequeñas y medianas empresas y también tenía todas las capacidades y el potencial para servir bien a las grandes empresas. Era una forma de pasar de una aplicación de software normal a una solución sofisticada y compleja que cumplía con los duros requisitos de escalabilidad, mantenibilidad y extensibilidad. Este texto proporcionará una visión general de lo que es el motor de reglas de negocio y describirá uno de los enfoques modernos para construirlo que puede considerar al construir este tipo de software.

Para empezar es importante definir los términos básicos. Los motores de reglas de negocio han existido en la industria durante mucho tiempo de una forma u otra y hay algunas definiciones dadas para casi todos los términos que vamos a utilizar. Empecemos por una «regla de negocio»: hay una definición bien conocida para este término. Así que una «regla de negocio» es:

Una declaración que define o restringe algún aspecto del negocio. Su objetivo es afirmar la estructura del negocio o controlar o influir en su comportamiento.

T. Morgan, Reglas de negocio y sistemas de información. Boston: Addison-Wesley Publishing, 2002

Las reglas de negocio tienen un alcance muy amplio y pueden aplicarse a cualquier aspecto del negocio. Por ejemplo, la regla «Cuando entre un cliente, salúdelo con una cálida sonrisa y un amistoso «Hola» es aplicada por el empleado de la empresa cuando se reúne con los clientes. Otra regla puede definir o restringir los enfoques para resolver tareas rutinarias por parte de un rol específico en una empresa. Con el aumento constante de la popularidad de las soluciones de software, como los sistemas CRM, y con la integración total del software en diversos ámbitos empresariales, la mayoría de los procesos empresariales se han orientado parcial o totalmente hacia los datos. Esto ha llevado a la transformación de las reglas de negocio para que se orienten al software, por ejemplo, la regla de negocio «Cuando un cliente compra algo en nuestra tienda, llámale más tarde para preguntarle si quiere comprar otros productos relacionados» se ha transformado en una más moderna «Cuando un cliente compra algo en nuestra tienda online envíale un correo electrónico con la lista de otros productos relacionados más tarde». Hoy en día, muchas empresas tratan principalmente con datos en sus operaciones diarias. Teniendo en cuenta que la mayoría de las empresas de todos los tamaños han integrado soluciones de software en sus actividades empresariales, la definición del término «regla de negocio» puede definirse de forma más específica añadiendo una aclaración (está en negrita) a la mencionada definición de T. Morgan:

Una regla de negocio es una declaración que define o restringe algún aspecto del negocio. Su objetivo es afirmar la estructura del negocio o controlar o influir en el comportamiento del negocio. Se almacena como una construcción de datos en el almacenamiento persistente y contiene un paquete atómico de lógica empresarial. Se gestiona y se aplica a los procesos de negocio de la empresa de forma automática a través de una solución de software.

Definido el término «regla de negocio», el término «Sistema de Gestión del Motor de Reglas de Negocio» (BRMS) se define de la siguiente manera:

BRMS es una solución de software para gestionar (almacenar, editar y eliminar, etc.) las reglas de negocio, así como para aplicarlas a los procesos de negocio de la empresa.

Los BRMS comerciales pueden ser extremadamente caros para comprar la licencia e integrarlos en la infraestructura de TI de la empresa, por lo que las empresas suelen implementar soluciones internas cuando se encuentran con la necesidad de automatizar los procesos de negocio u otro tipo de procesos.
Los BRMS pueden convertirse en una parte esencial y vital de cualquier negocio. A veces el éxito de un negocio puede depender de las reglas de negocio que tenga y de lo bien que se gestionen y apliquen estas reglas de negocio.

La construcción de datos de reglas de negocio

Una regla de negocio puede representarse como una serie consecuente de comandos atómicos. Los comandos pueden incluir análisis de datos condicionales, comandos de espera de tiempo, comandos de ejecución de acciones, etc. El ejemplo de regla de negocio «Cuando un cliente compra algo en nuestra tienda online envíale un correo electrónico con la lista de otros productos relacionados más adelante» es bueno y genérico y muchas otras reglas de negocio pueden tener una estructura lógica muy similar:

El flujo de procesamiento de la regla se inicia cuando se ha realizado una compra y se aplica cierta lógica de negocio ejecutando el comando «Enviar al comprador un correo electrónico con las ofertas de bienes relevantes». Puede ocurrir que el comprador haya desactivado la suscripción al correo electrónico. Entonces, hay que añadir la condición adicional a la regla de negocio – «si el comprador tiene habilitada la suscripción por correo electrónico»:

Los comandos se ejecutan consecuentemente y ahora hay un comando de análisis de datos para comprobar si el comprador tiene una suscripción por correo electrónico activa. Si es así – se procede a la ejecución del siguiente comando de la regla de negocio. Y si no – no se procede, la regla de negocio se considera terminada, el flujo de procesamiento se detiene, los comandos subsiguientes no se ejecutan.

El comprador también puede tener una suscripción de SMS, y si está activa, debe haber otro comando también – «Enviar un SMS con oferta promocional relacionada». Con esto, se introduce la ramificación en la lógica de la regla de negocio:

Las ramas de la regla se procesan independientemente unas de otras. El procesamiento de una de las ramas puede detenerse en el comando de evaluación de la condición y otra rama puede ser procesada hasta el final.

La interfaz de usuario de la aplicación del lado del cliente del BRMS para representar una regla de negocio puede ser implementada de varias maneras (cualquier tipo de representación gráfica de árbol funcionará):

La construcción de datos de las reglas de negocio es un grafo de árbol enraizado dirigido (un grafo acíclico dirigido, que tiene un árbol como grafo no dirigido subyacente). Los vértices del gráfico de reglas de negocio se representan con diferentes tipos de comandos: comandos de análisis de datos, comandos de ejecución de acciones, comandos de tiempo de espera, etc. Cada árbol dirigido y enraizado tiene una raíz, un vértice que tiene todas las aristas que salen de él. Por lo tanto, cada regla comienza con un vértice especial (o vértice raíz en términos de teoría de grafos) – el vértice que designa el punto de entrada para el procesamiento de la regla.

Operaciones CRUD en la construcción de datos de reglas de negocio

Dado que la construcción de datos se representa con un árbol enraizado dirigido y nunca con cualquier otro tipo de gráfico, esto nos libera de los inconvenientes que acompañan al almacenamiento de las estructuras de gráficos generales con RDBMS (como el almacenamiento de los vértices y aristas en diferentes tablas que pueden resultar en un mayor número de búsquedas para una sola recuperación de la regla, etc.). Y esto es crítico porque está claro que durante las operaciones normales del BRMS las búsquedas de datos ocurren mucho más a menudo, que otras operaciones como inserciones, actualizaciones o eliminaciones.

Sólo como recordatorio – cada vértice de la regla de negocio representa un comando atómico. Se guarda en la tabla del RDBMS como un registro con atributos como el tipo de comando, la descripción y otros datos complementarios. En un árbol, cada vértice tiene uno y sólo uno de sus padres (excepto el vértice raíz, que no tiene padres), por lo que cada registro debe contener un ID del vértice padre. También es conveniente tener otra tabla que albergue los registros de las reglas con los datos relevantes para la propia regla de negocio. No hay ningún problema con el almacenamiento de las construcciones de datos de las reglas de negocio de cualquier complejidad con este enfoque.

Las operaciones CRUD son bastante sencillas. Los cambios en las reglas de negocio pueden requerir actualizaciones en una o ambas tablas – regla o comando. Al borrar o insertar comandos es necesario mantener las referencias entre los comandos (esto es esencialmente borrar o insertar nodos a un árbol).

Uno de los componentes del BRMS, llamémoslo gestor, debe realizar las operaciones de base de datos descritas y proporcionar una API para las operaciones CRUD en las reglas de negocio.

El procesamiento de la regla de negocio

El procesamiento de la regla de negocio comienza cuando ocurre un evento de negocio particular. Puede ser cualquier cosa – un usuario se ha conectado, se ha hecho una compra, se ha transferido alguna cantidad de dinero, etc. Este tipo de actividad debe ser rastreada y el BRMS debe ser informado sobre ella a través de algún transporte. AMQP es probablemente el más adecuado para este tipo de tareas.

1. Todo el concepto está construido sobre una arquitectura de microservicios. El microservicio consumidor de eventos de negocio escucha todos los eventos de negocio a través de la declaración de una cola y la vinculación a un intercambio específico en un servidor de intercambio RabbitMQ. Cuando una actividad de negocio (que se considera significativa y se rastrea) ocurre en el sistema de software principal, el mensaje se envía al servidor de intercambio RabbitMQ. Contiene información sobre lo que ha sucedido, así como algunos datos complementarios relevantes. El evento puede identificarse con un atributo de cualquier tipo pasado en el mensaje o utilizado como clave de enrutamiento, por ejemplo, una cadena purchase.completed. A continuación, el mensaje es consumido por el microservicio consumidor de eventos de negocio BRMS.

2. Cuando el microservicio consumidor de eventos de negocio recibe el mensaje del sistema de software principal, entonces consulta al microservicio gestor si hay alguna regla de negocio en la base de datos que tenga el disparador de reglas apropiado para el evento de actividad de negocio. Y si existe tal regla de negocio que coincida, el microservicio gestor devuelve los datos del comando inicial al microservicio consumidor de eventos. Esta recuperación de datos del gestor se realiza a través de gRPC y se visualiza con una línea discontinua.

3. Justo después de que el microservicio gestor responda con los datos del comando inicial, el microservicio consumidor de eventos de negocio está listo para iniciar el procesamiento de la regla de negocio. El consumidor de eventos forma otro mensaje que encapsula los datos del comando inicial (recibidos del microservicio gestor), y los datos del evento de negocio, recibidos del sistema de software principal. Lo envía a través del AMQP a un intercambio interno de BRMS. La clave de enrutamiento del mensaje corresponde al tipo de comando.

4. El microservicio de procesamiento inicial de comandos consume el mensaje (escucha la cola donde se apilan los mensajes con clave de enrutamiento initial). Luego hace su lógica (en un caso básico el bloque inicial no alberga ninguna lógica) y consulta al gestor si hay comandos posteriores en la regla de negocio (son los comandos con parent_id igual al id del comando que se procesa actualmente). Y si es así, recibe los datos de la siguiente orden y envía tanto los datos del evento como los de la siguiente orden al servidor interno RabbitMQ. Sí, ahora parece un recorrido de lista enlazada, ¡y cuando la regla tiene ramas es un recorrido de árbol! Así es como la regla de negocio está siendo procesada comando a comando. Otra cosa importante aquí – en ese contexto, los datos del evento son pasados a cada comando hijo. Es un contexto de la ejecución de la regla de negocio única. Puede ser utilizado más tarde en el procesador de comandos de análisis de datos y el procesador de comandos de acción.

Para propósitos de ilustración vamos a suponer que la regla de ejemplo tiene una estructura como esta: comando inicial -> comando de análisis de datos condicional -> comando de acción de negocio. Entonces el siguiente comando después del inicial es el comando de análisis de datos.

5. El procesador de comandos de análisis consume el mensaje con la clave de enrutamiento analysis del intercambio interno. Basado en la evaluación de las condiciones, que se describen en el comando de análisis de la regla de negocio y utilizando los datos del evento de negocio, el flujo de ejecución de la regla puede continuar o detenerse aquí. Si se detiene, no se ejecutan más comandos de la regla de negocio. Si el flujo de ejecución continúa, el procesador de comandos de análisis consulta al gestor los siguientes comandos de reglas de negocio, los recupera y publica otro mensaje al servidor de intercambio interno.

6. Finalmente, hay un mensaje en el intercambio interno, que está listo para que el procesador de comandos de acción lo consuma. Si el flujo de ejecución de la regla de negocio ha llegado hasta este comando, significa que en esta rama de la regla todas las condiciones que había en el comando de análisis de datos eran verdaderas y el flujo de ejecución no se interrumpió. El procesador de comandos de acción ejecuta la acción, por ejemplo, envía un correo electrónico.

Este tipo de recorrido del gráfico es de primera profundidad, y cuando se encuentra un comando con 2 o más comandos hijos, el recorrido de primera profundidad simultánea comienza para cada rama debido a la naturaleza asíncrona del procesamiento de reglas de negocio en el sistema descrito.

Escalado

El enfoque descrito permite no sólo una gran separación de preocupaciones, sino que también puede ahorrar mucho dinero a la hora de pagar las facturas de IaaS. Los usuarios finales crean una variedad de reglas de negocio con diferentes números de comandos de diferentes tipos y diferentes números de ramas. Pero los escenarios comunes de escalado son los siguientes:
1. El número de eventos de negocio aumenta – el consumidor de eventos de negocio se escala.
2. El número de reglas de negocio asociadas (disparadas) por los eventos de negocio aumenta – el procesador de comandos iniciales se escala junto con el gestor.
3. Hay muchos comandos de análisis en las reglas de negocio – el procesador de comandos de análisis se escala
4. Hay que ejecutar demasiados comandos de acción – el procesador de comandos de acción se escala.

Fiabilidad

El vaso sanguíneo del sistema es el transporte. Para que el sistema permanezca operativo bajo una alta carga, el intercambio interno de mensajes debe ser altamente fiable. RabbitMQ proporciona clustering y satisface bien los requisitos de fiabilidad (https://www.rabbitmq.com/clustering.html).

Otros tipos de comandos

Se puede introducir cualquier otra lógica de negocio en el sistema. Uno de los tipos de comando más populares y demandados es el comando de tiempo de espera (por ejemplo, ‘Espere 45 minutos, luego continúe’). Con la introducción del comando de tiempo de espera, el procesamiento de la regla de negocio ya no es un procesamiento en tiempo real, ya que puede ser suspendido durante algún tiempo. Estos cambios requieren procesadores de comandos adicionales y algunos ajustes en las estructuras de datos que están fuera del alcance de este texto. Jugar con el tiempo puede ser difícil y escribir un servicio que opere los horarios y el tiempo puede ser un reto, aquí hay un ejemplo de uno bueno: https://github.com/nextiva/krolib

Alternativas de terceros

Hay alternativas bien conocidas de motores de reglas/motores de flujo de trabajo, aquí están los 3 mejores de ellos (IMHO):
1. Comunda – es un producto maduro con versiones comunitarias y empresariales, que puede querer utilizar. Obviamente, la versión empresarial es de pago.
2. Luigi – es una herramienta de motor de flujo de trabajo desarrollado por Spotify para sus necesidades internas, pero ya utilizado por decenas de otras empresas.
3. Apache Airflow – este es otro producto bien conocido que ha demostrado ser capaz, conveniente y personalizable.

Lo que une a estas herramientas, es que todos ellos utilizan gráficos acíclicos directos como la estructura de datos que representa las reglas de negocio o flujos de trabajo. No es una sorpresa.

Puede haber otros productos que merezcan la pena, pero cualquier investigación debería empezar por estos tres.

Conclusión

Construir tu propio motor de reglas de negocio puede ser un reto, pero es gratificante. No sólo se obtiene un sistema propio, sino que se construye de acuerdo con los requisitos específicos de su negocio. Un buen equipo de DevOps es imprescindible cuando se trata de mantener la fiabilidad, la escalabilidad y la supervisión. Al fin y al cabo, obtienes un producto fantástico del que puedes estar orgulloso.