rule engine - open - Motor de reglas: pros y contras

motor de reglas de negocio (12)

Muchas buenas respuestas, pero quería agregar algunas cosas:

al automatizar una decisión de cualquier complejidad, lo más crítico se convierte rápidamente en su capacidad para administrar en lugar de ejecutar la lógica involucrada. Un motor de reglas no ayudará con esto: debe pensar en las capacidades de administración de reglas que tiene un sistema de administración de reglas comerciales. La mayoría de los motores de reglas comerciales y de código abierto se han convertido en sistemas de administración de reglas con repositorios, informes sobre uso de reglas, control de versiones, etc. Un repositorio de reglas, estructurado en conjuntos de reglas coherentes que pueden orquestarse para tomar decisiones comerciales es mucho más fácil de administrar que cualquiera miles de líneas de código o una sopa de reglas.
Hay muchas maneras de usar un enfoque declarativo basado en reglas. El uso de reglas para administrar una IU o como parte de la definición de un proceso puede ser muy efectivo. El uso más valioso de un enfoque de reglas, sin embargo, es automatizar las decisiones comerciales y entregar esto como servicios de decisión poco compactos que toman entrada, ejecutan reglas y devuelven una respuesta, una decisión. Estos servicios responden a preguntas de otros servicios como "¿este cliente es un buen riesgo de crédito" o "qué descuento le debo dar a este cliente por este pedido?" O "cuál es el mejor venta cruzada para este cliente en este momento". Estos servicios de decisión se pueden construir de manera muy efectiva utilizando un sistema de administración de reglas y permiten una integración sencilla de análisis con el tiempo, algo de lo que muchas decisiones se benefician.

Estoy auditando un proyecto que usa lo que se llama un motor de reglas . En resumen, es una forma de externalizar la lógica empresarial desde el código de la aplicación.

Este concepto es completamente nuevo para mí y soy bastante escéptico al respecto. Después de escuchar a la gente hablar acerca de los Modelos de Dominio Anemico durante los últimos años, estoy cuestionando el Enfoque del Motor de Reglas. Para mí, parecen una excelente manera de DEBILITAR un modelo de dominio. Por ejemplo, decir que estoy haciendo una aplicación web Java interactuando con un motor de reglas. Luego decido que quiero tener una aplicación de Android basada en el mismo dominio. A menos que quiera que la aplicación de Android también interactúe con el motor de reglas, tendré que perderme la lógica de negocios que ya estaba escrita.

Como aún no tengo ninguna experiencia con ellos, solo curiosidad, estaba interesado en conocer los pros y los contras del uso de un motor de reglas. El único profesional que se me ocurre es que no necesitas reconstruir toda tu aplicación solo para cambiar algunas reglas de negocios (pero, en realidad, ¿cuántas aplicaciones realmente tienen tantos cambios?). Pero usar un motor de reglas para resolver ese tipo de problema me suena como poner una tirita sobre una herida de escopeta.

ACTUALIZACIÓN: desde que se escribió esto, el mismo dios, Martin Fowler, ha escrito sobre el uso de un motor de Reglas .

"pero en realidad, ¿cuántas aplicaciones realmente tienen tantos cambios?"

Honestamente, cada aplicación en la que he trabajado ha pasado por un flujo de trabajo serio y / o cambios lógicos desde el concepto hasta bien después de la implementación. Es la razón número uno para la programación de "mantenimiento" ...

La realidad es que no se puede pensar en todo por adelantado, de ahí la razón de los procesos ágiles. Además, los BA siempre parecen perder algo vital hasta que se encuentra en las pruebas.

Los motores de reglas le obligan a separar verdaderamente la lógica empresarial de la presentación y el almacenamiento. Además, si utiliza el motor correcto, sus BA pueden agregar y eliminar lógica según sea necesario. Como dijo Chris Marasti-Georg, pone la responsabilidad del BA. Pero más que eso, le permite al BA obtener exactamente lo que están pidiendo.

(Como todo lo demás) depende de su aplicación. Para algunas aplicaciones (generalmente las que nunca cambian o las reglas son mejores en las constantes de la vida real, es decir, no cambiarán notablemente en eones, por ejemplo, propiedades físicas y fórmulas) no tiene sentido utilizar un motor de reglas, simplemente introduce complejidad adicional y requiere que el desarrollador tenga un conjunto de habilidades más grande.

Para otras aplicaciones, es realmente una buena idea. Tomemos por ejemplo el procesamiento de órdenes (las órdenes son desde la facturación hasta el procesamiento de transacciones de divisas), de vez en cuando hay un cambio de un minuto a alguna ley o código relevante (en el sentido judicial) que requiere cumplir con un nuevo requisito (por ejemplo, impuesto a las ventas , un clásico). En lugar de tratar de forzar su aplicación anterior a esta nueva situación donde de repente tiene que pensar en el impuesto a las ventas, donde antes no lo hacía, es más fácil adaptar su conjunto de reglas en lugar de tener que inmiscuirse en una gran conjunto de tu código.

Luego, la próxima modificación de su gobierno local requiere la presentación de informes de todas las ventas dentro de ciertos criterios, en lugar de tener que ingresar y agregar eso también. Al final terminarás con un código muy complejo que resultará bastante difícil de manejar cuando cambies y quieras revertir el efecto de una de las reglas, sin influenciar a todos los demás ...

El mayor profesional que he visto para los motores de reglas es que permite a los propietarios de reglas empresariales implementar las reglas de negocio, en lugar de poner la responsabilidad en los programadores. Incluso si tiene un proceso ágil en el que constantemente obtiene retroalimentación de las partes interesadas y pasa por iteraciones rápidas, todavía no se logrará el nivel de eficiencia que se puede lograr haciendo que las personas que elaboran las reglas de negocio también las implementen.

Además, no puede subestimar el valor al eliminar el ciclo de recompilación-repetición-reimplantación que puede resultar de un simple cambio de regla, si las reglas están incorporadas en el código. A menudo hay varios equipos que participan en la creación de una bendición, y el uso de un motor de reglas puede hacer que gran parte de eso sea innecesario.

Los motores de reglas pueden ofrecer mucho valor, en ciertos casos.

En primer lugar, muchos motores de reglas funcionan de una manera más declarativa. Un ejemplo muy crudo sería AWK, donde puede asignar expresiones regulares a bloques de código. Cuando el escáner de archivos ve la expresión regular, se ejecuta el bloque de código.

Puedes ver que en este caso, si tuvieras, digamos, un gran archivo AWK y quisieras agregar Otra "regla", puedes ir al final del archivo, agregarle expresiones regex y lógica, y terminar con eso. Específicamente, para muchas aplicaciones, no está particularmente interesado en lo que hacen las otras reglas, y las reglas realmente no interoperan entre sí.

Por lo tanto, el archivo AWK se parece más a una "sopa de reglas". Esta naturaleza de "sopa de reglas" permite a las personas enfocarse muy estrechamente en sus dominios con poca preocupación por todas las otras reglas que pueden estar en el sistema.

Por ejemplo, Frank está interesado en pedidos con un total de más de $ 1000, por lo que pone en el sistema de reglas que le interesa. "SI order.total> 1000 THEN correo electrónico Frank".

Mientras tanto, Sally quiere todas las órdenes de la costa oeste: "IF order.source == ''WEST_COAST'' ENTONCES envíe un correo electrónico a Sally".

Entonces, puede ver en este caso trivial y artificial que una orden puede satisfacer ambas reglas, pero ambas reglas son independientes entre sí. Un pedido de $ 1200 de la costa oeste notifica a Frank y a Sally. Cuando Frank ya no esté preocupado, simplemente sacará su regla de la sopa.

Para muchas situaciones, esta flexibilidad puede ser muy poderosa. También puede, como este caso, exponerse a los usuarios finales por reglas simples. Usando expresiones de alto nivel y tal vez scripting liviano.

Ahora, claramente, en un sistema complicado existen todo tipo de interrelaciones que pueden suceder, y esta es la razón por la cual todo el sistema no está "Hecho con reglas". Alguien, en alguna parte, estará a cargo de que las reglas no se salgan de control. Pero eso no necesariamente disminuye el valor que un sistema así puede proporcionar.

Tenga en cuenta que esto ni siquiera entra en cosas como los sistemas expertos, donde las reglas se basan en datos que las reglas pueden crear, pero un sistema de reglas más simple.

De todos modos, espero que este ejemplo muestre cómo un sistema de reglas puede ayudar a aumentar una aplicación más grande.

Todos hasta ahora han sido muy positivos con respecto a los motores de reglas, pero aconsejo al lector que sea cauteloso. Cuando un problema se vuelve un poco más complicado, de repente puede descubrir que un motor de reglas completo se ha vuelto inadecuado, o mucho más complicado que en un lenguaje más potente. Además, para muchos problemas, los motores de reglas no podrán detectar fácilmente las propiedades que reducen en gran medida el tiempo de ejecución y la huella de memoria al evaluar la condición. Hay relativamente pocas situaciones en las que preferiría un motor de reglas a un marco de inyección de dependencias o un lenguaje de programación más dinámico.

Un motor de reglas es una ganancia en una aplicación configurable en la que no desea tener que hacer compilaciones personalizadas si puede evitarse. También son buenos para centralizar grandes bases de reglas y los algoritmos como Rete son eficientes para hacer correspondencias rápidas con grandes conjuntos de reglas.

Creo que sus preocupaciones sobre los modelos de dominio anémicos son válidos.

He visto dos aplicaciones de un conocido motor comercial de reglas Rete funcionando en producción donde trabajo. Consideraría uno un éxito y el otro un fracaso.

La aplicación exitosa es una aplicación de árbol de decisión, que consta de ~ 10 árboles de ~ 30 puntos de ramificación cada uno. El motor de reglas tiene una interfaz de usuario que permite a las personas de negocios mantener las reglas.

La aplicación menos exitosa tiene ~ 3000 reglas atacadas en una base de datos de reglas. Nadie tiene idea de si hay reglas contradictorias cuando se agrega una nueva. Hay poca comprensión del algoritmo Rete, y la experiencia con el producto ha salido de la empresa, por lo que se ha convertido en una caja negra que es intocable e irreparable. El ciclo de implementación aún se ve afectado por los cambios en las reglas; se debe realizar una prueba de regresión completa cuando se cambian las reglas. La memoria también era un problema.

Me gustaría pisar a la ligera. Cuando un conjunto de reglas es de tamaño modesto, es fácil entender los cambios, como la muestra simplista de correo electrónico que se indicó anteriormente. Una vez que la cantidad de reglas asciende a cientos, creo que es posible que tenga un problema.

También me preocuparía que un motor de reglas se convierta en un cuello de botella único en su aplicación.

No veo nada de malo con el uso de objetos como una forma de partición del espacio del motor de reglas. Incrustar el comportamiento en objetos que difieren en un motor de reglas privadas me parece bien. Los problemas lo golpearán cuando el motor de reglas requiera un estado que no sea parte de su objeto para disparar correctamente. Pero ese es solo otro ejemplo de que el diseño es difícil.

Veo que los motores de reglas, procesos y datos (también conocidos como bases de datos) son esencialmente similares. Pero, por alguna razón, nunca decimos que el blackboxing del subsistema de persistencia es malo.

En segundo lugar, desde mi punto de vista, un modelo anémico no es uno que es ligero en la implementación de comportamientos, es uno que es ligero en los comportamientos en sí mismo . El método real que describe un comportamiento disponible en un objeto de modelo de dominio no tiene que ser hecho por el objeto mismo.

He escrito un motor de reglas para un cliente. El mayor logro fue incluir a todas las partes interesadas. El motor podría ejecutar (o reproducir) una consulta y explicar lo que estaba sucediendo en el texto. Los empresarios pueden ver la descripción del texto y señalar rápidamente los matices en las reglas, excepciones y otros casos especiales. Una vez que el lado del negocio estuvo involucrado, la validación se mejoró mucho porque era fácil obtener su opinión. Además, el motor de reglas puede vivir por separado de otras partes de una base de código de aplicación para que pueda usarlo en todas las aplicaciones.

La estafa es que a algunos programadores no les gusta aprender demasiado. Los motores de reglas y las reglas que les pones, junto con las cosas que los implementan, pueden ser un poco peludos. Aunque un buen sistema puede manejar fácilmente redes de lógica enfermas y retorcidas (o ilógicas a menudo;), no es tan simple como codificar un montón de sentencias if (sin importar lo que hagan algunos de los motores de reglas simples). El motor de reglas le brinda las herramientas para manejar las relaciones entre reglas, pero aún debe ser capaz de imaginar todo eso en su mente. A veces es como vivir en la película Brasil . :)

La mayor complejidad de mi experiencia en Rule Engines es que:

de OOP POV es una verdadera molestia refactorizar y probar las reglas escritas en un lenguaje declarativo mientras refactoriza el código que las afecta.
A menudo, siempre debemos pensar en el orden de ejecución de las reglas que se convierte en un desastre cuando hay muchas.
Algunos cambios menores pueden desencadenar un comportamiento incorrecto de las reglas que conducen a errores de producción. En la práctica, no siempre es posible cubrir todos los casos con pruebas iniciales.
Las reglas que mutan los objetos utilizados en otras también aumentan la complejidad, lo que hace que los desarrolladores las dividan en etapas.

La mayoría de los motores de reglas que he visto se ven como una caja negra por el código del sistema. Si tuviera que construir un modelo de dominio, probablemente querría que ciertas reglas comerciales fueran intrínsecas al modelo de dominio, por ejemplo, reglas comerciales que me dicen cuándo un objeto tiene valores no válidos. Esto permite que varios sistemas compartan el modelo de dominio sin duplicar la lógica comercial. Podría hacer que cada sistema use el mismo servicio de reglas para validar mi modelo de dominio, pero esto parece debilitar mi modelo de dominio (como se señaló en la pregunta). ¿Por qué? Porque en lugar de aplicar constantemente mis reglas comerciales en todos los sistemas en todo momento, confío en los programadores del sistema para determinar cuándo se deben aplicar las reglas comerciales (llamando al servicio de reglas). Esto puede no ser un problema si el modelo de dominio viene completamente poblado, pero puede ser problemático si se trata de una interfaz de usuario o sistema que cambia los valores en el modelo de dominio a lo largo de su vida útil.

Existe otra clase de reglas comerciales: la toma de decisiones. Por ejemplo, una compañía de seguros puede necesitar clasificar el riesgo de suscribir a un solicitante y llegar a una prima. Puede colocar estos tipos de reglas comerciales en su modelo de dominio, pero una decisión centralizada para escenarios como este suele ser deseable y, de hecho, se ajusta bastante bien a una arquitectura orientada a servicios. Esto plantea la pregunta de por qué un motor de reglas y no un código de sistema. El lugar donde un motor de reglas puede ser una mejor opción es cuando las reglas comerciales responsables de la decisión cambian con el tiempo (como algunas otras respuestas han señalado).

Los motores de reglas generalmente le permiten cambiar reglas sin reiniciar su sistema o implementar nuevos códigos ejecutables (independientemente de las promesas que reciba de un proveedor, asegúrese de probar los cambios en un entorno que no sea de producción porque, incluso si el motor de reglas es impecable) , los humanos todavía están cambiando las reglas). Si está pensando: "Puedo hacerlo utilizando una base de datos para almacenar valores que cambian", tiene razón. Un motor de reglas no es una caja mágica que hace algo nuevo. Está destinado a ser una herramienta que proporciona un mayor nivel de abstracción para que pueda centrarse menos en la reinvención de la rueda. Muchos proveedores dan un paso más al permitirle crear plantillas para que los usuarios comerciales puedan completar los espacios en blanco en lugar de aprender un lenguaje de reglas.

Una precaución de separación sobre las plantillas: las plantillas nunca pueden tomar menos tiempo que escribir una regla sin una plantilla porque la plantilla debe, como mínimo, describir la regla. Planee un costo inicial más alto (lo mismo que si construyera un sistema que utilizara una base de datos para almacenar valores que cambian en lugar de escribir las reglas directamente en el código del sistema) - el retorno de la inversión se debe a que ahorra mantenimiento futuro del código del sistema .