Motor de reglas - pros y contras

Question

Estoy auditando un proyecto que utiliza lo que se llama un Motor de reglas . En resumen, es una forma de externalizar la lógica empresarial del 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 las personas hablar sobre Modelos de Dominios Anémicos durante los últimos años, estoy cuestionando el Enfoque del motor de reglas. Para mí, parecen ser una excelente manera de DESGASTAR un modelo de dominio. Por ejemplo, digamos que estoy haciendo una aplicación web java interactuando con un motor de reglas. Entonces decido que quiero tener una aplicación de Android basada en el mismo dominio. A menos que yo también quiera que la aplicación de Android interactúe con el motor de reglas, voy a tener que perder la lógica de negocios que ya estaba escrita.

Como todavía no tengo experiencia con ellos, solo curiosidad, me interesó saber sobre los pros y los contras de usar un motor de reglas. El único profesional en el que puedo pensar es que no necesita reconstruir su aplicación completa solo para cambiar alguna regla de negocios (pero, en realidad, ¿cuántas aplicaciones tienen realmente tantos cambios?). Pero usar un Motor de Reglas para resolver ese tipo de problemas que me suenan como poner una curita sobre una herida de escopeta.

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

Answer 1

La mayoría de los motores de reglas que he visto se ven como una caja negra por código de sistema. Si tuviera que construir un modelo de dominio, probablemente querría que ciertas reglas de negocio sean intrínsecas al modelo de dominio, por ejemplo. Reglas de negocios que me dicen cuando un objeto tiene valores inválidos. Esto permite que múltiples sistemas compartan el modelo de dominio sin duplicar la lógica empresarial. 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 hacer cumplir de manera consistente mis reglas de negocios en todos los sistemas en todo momento, confío en los programadores de sistemas para determinar cuándo se deben hacer cumplir las reglas de negocios (llamando al servicio de reglas). Es posible que esto no sea un problema si el modelo de dominio está completamente poblado, pero puede ser problemático si está tratando con una interfaz de usuario o un sistema que cambia los valores del modelo de dominio a lo largo de su vida útil.

Hay otra clase de reglas de negocio: toma de decisiones. Por ejemplo, una compañía de seguros puede necesitar clasificar el riesgo de suscribir a un solicitante y obtener una prima. Podría colocar estos tipos de reglas de negocio en su modelo de dominio, pero una decisión centralizada para escenarios como este suele ser deseable y, en realidad, encaja bastante bien en 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 donde las reglas comerciales responsables de la decisión cambian con el tiempo (como han señalado otras respuestas).

Los motores de reglas generalmente le permiten cambiar las reglas sin reiniciar su sistema o implementar un nuevo código ejecutable (independientemente de las promesas que reciba de un proveedor, asegúrese de probar sus cambios en un entorno no productivo porque, incluso si la regla El motor es impecable, los humanos todavía están cambiando las reglas). Si estás pensando, " Puedo hacerlo usando una base de datos para almacenar valores que cambian " ;, tienes razón. Un motor de reglas no es una caja mágica que hace algo nuevo. Está pensado para ser una herramienta que proporciona un mayor nivel de abstracción para que pueda concentrarse menos en reinventar la rueda. Muchos proveedores llevan esto un paso más allá 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 despedida 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. Planifique un costo inicial más alto (igual que si construyera un sistema que usara una base de datos para almacenar valores que cambian versus escribir las reglas directamente en el código del sistema): el ROI se debe a que ahorra en el mantenimiento futuro del código del sistema .

Answer 2

Creo que sus preocupaciones sobre los modelos de dominio anémico son válidas.

He visto dos aplicaciones de un conocido motor comercial de reglas de Rete ejecutándose en producción donde trabajo. Considero que uno es 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 golpeadas en una base de datos de reglas. Nadie tiene idea de si hay reglas en conflicto cuando se agrega una nueva. Hay poca comprensión del algoritmo de Rete, y la experiencia con el producto ha dejado a la empresa, por lo que se ha convertido en una caja negra que no se puede tocar ni refutar. 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.

Pisaría ligeramente. Cuando un conjunto de reglas es de tamaño modesto, es fácil comprender los cambios, como el ejemplo de correo electrónico simplista que se muestra arriba. Una vez que el número de reglas asciende a cientos, creo que podría tener 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 malo en usar objetos como una forma de partición que gobierna el espacio del motor. El comportamiento de incrustación en objetos que difieren a un motor de reglas privado me parece bien. Los problemas lo afectarán cuando el motor de reglas requiera un estado que no sea parte de su objeto para disparar correctamente. Pero eso es solo otro ejemplo de que el diseño es difícil.

Answer 3

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

Primero, muchos motores de reglas funcionan de una manera más declarativa. Un ejemplo muy básico sería AWK, donde puedes asignar expresiones regulares a bloques de código. Cuando el explorador de archivos ve la expresión regular, se ejecuta el bloque de código.

Puedes ver que en este caso, si tuvieras, digamos, un archivo AWK grande y quisieras agregar la regla Yet Another "quot quot", puedes ir fácilmente al final del archivo, agregar la expresión regular y la lógica, y que se acabe con eso. Específicamente, para muchas aplicaciones, no está particularmente preocupado por lo que hacen las otras reglas, y las reglas realmente no interactúan entre sí.

Por lo tanto, el archivo AWK se parece más a una " sopa de reglas " ;. Esta "regla de la sopa" la naturaleza permite que las personas se enfoquen muy estrechamente en su dominio 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 se suma al sistema de reglas que le interesa. " SI order.total > 1000 ENTONCES correo electrónico Frank " ;.

Mientras tanto, Sally quiere todos los pedidos de la costa oeste: " IF order.source == 'WEST_COAST' LUEGO, envíe un correo electrónico a Sally " ;.

Por lo tanto, puede ver en este caso trivial, ideado, que una orden puede satisfacer ambas reglas, aunque ambas reglas son independientes entre sí. Un pedido de $ 1200 de la costa oeste notifica a Frank y 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, estar expuesto a usuarios finales para reglas simples. Utilizando expresiones de alto nivel y quizás scripts ligeros.

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

Tenga en cuenta que esto no se aplica a los sistemas expertos, donde las reglas se disparan a los datos que las reglas pueden crear, sino a 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.

Answer 4

El mayor profesional que he visto para los motores de reglas es que permite a los propietarios de Reglas de Negocio implementar las reglas de negocio, en lugar de poner la responsabilidad en los programadores. Incluso si tiene un proceso ágil en el que constantemente recibe comentarios de las partes interesadas y atraviesa iteraciones rápidas, todavía no va a lograr el nivel de eficiencia que se puede lograr al hacer que las personas que hacen las reglas de negocios las implementen también. p>

Además, no puede subestimar el valor al eliminar el ciclo de recompilación-re-prueba-redistribución que puede resultar de un simple cambio de regla, si las reglas están incrustadas en el código. A menudo hay varios equipos que participan en la construcción de la bendición, y el uso de un motor de reglas puede hacer que gran parte de esto sea innecesario.

Answer 5

He escrito un motor de reglas para un cliente. La mayor victoria fue incluir a todos los interesados. 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 de las reglas, excepciones y otros casos especiales. Una vez que el lado comercial estuvo involucrado, la validación mejoró mucho porque fue fácil obtener su aporte. Además, el motor de reglas puede vivir por separado de otras partes de la base de código de una aplicación para que pueda usarlo en todas las aplicaciones.

La desventaja es que a algunos programadores no les gusta aprender demasiado. Los motores de reglas y las reglas que pones en ellos, junto con las cosas que los implementan, pueden ser un poco complicados. 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 declaraciones if (no importa cuál sea la lógica de los motores de reglas) hacer). El motor de reglas te brinda las herramientas para manejar las relaciones de reglas, pero aún así debes poder imaginar todo eso en tu mente. A veces es como vivir en la película Brasil . :)

Answer 6

Esto (como todo lo demás) depende de tu 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 usar un motor de reglas, simplemente introduce complejidad adicional y requiere que el desarrollador tenga un conjunto de habilidades más amplio.

Para otras aplicaciones es realmente una buena idea. Por ejemplo, el procesamiento de pedidos (los pedidos son cualquier cosa, desde la facturación hasta el procesamiento de transacciones en efectivo), de vez en cuando hay un cambio minucioso en alguna ley o código relevante (en el sentido judicial) que requiere que cumpla con un nuevo requisito (por ejemplo, impuesto a las ventas). , un clásico). En lugar de intentar forzar su antigua aplicación en esta nueva situación en la que de repente tiene que pensar en el impuesto sobre las ventas, donde como antes no lo hacía, es más fácil adaptar su conjunto de reglas en lugar de tener que meterse en una gran cantidad conjunto de su código.

Luego, la próxima enmienda de su gobierno local requiere que se informe de todas las ventas dentro de un cierto criterio, en lugar de que tenga que ingresar y agregar eso también. Al final, terminará con un código muy complejo que resultará bastante difícil de administrar cuando se dé la vuelta y desee revertir el efecto de una de las reglas, sin influir en las demás ...

Answer 7

Hasta ahora, todo el mundo ha sido muy positivo con los motores de reglas, pero le aconsejo al lector que sea cauteloso. Cuando un problema se vuelve un poco más complicado, puede encontrar de repente que todo un motor de reglas se ha vuelto inadecuado o mucho más complicado que en un lenguaje más poderoso. 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.

Answer 8

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

Honestamente, todas las aplicaciones en las que he trabajado han pasado por un flujo de trabajo serio y / o cambios lógicos desde el concepto hasta mucho después de la implementación. Es la razón número uno para " mantenimiento " programando ...

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

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

Answer 9

Un motor de reglas es un triunfo en una aplicación configurable donde no desea tener que hacer compilaciones personalizadas si se puede evitar. También son buenos para centralizar grandes bases de reglas y algoritmos como Rete son eficaces para una rápida comparación con grandes conjuntos de reglas.

Answer 10

Muchas respuestas buenas ya, pero quería agregar un par de cosas:

1. Al automatizar una decisión de cualquier complejidad, lo crítico se convierte rápidamente en su capacidad de 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 de negocios. La mayoría de los motores de reglas comerciales y de código abierto se han convertido en sistemas de gestión de reglas con repositorios, informes sobre el uso de las reglas, control de versiones, etc. Miles de líneas de código o una sopa de reglas.
2. Hay muchas maneras de usar un enfoque declarativo basado en reglas. Usar 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 de negocios y entregar esto como servicios de decisión acoplados libremente que toman información, ejecutan reglas y devuelven una respuesta: una decisión. La cosa de estos como servicios que responden preguntas para otros servicios como "este cliente es un buen riesgo crediticio" o " ¿qué descuento debo darle a este cliente para este pedido o " cuál es la mejor venta cruzada para este cliente en este momento? Estos servicios de decisión pueden construirse de manera muy efectiva utilizando un sistema de gestión de reglas y permiten una fácil integración de los análisis a lo largo del tiempo, algo de lo que muchas decisiones se benefician.

Answer 11

Veo que los motores de reglas, procesos y datos (a.k.a. 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 sea ligero en implementación de comportamientos, es uno que es ligero en comportamientos en sí mismo . El método en sí que describe un comportamiento disponible en un objeto de modelo de dominio no tiene que hacerlo el propio objeto.

Answer 12

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

1. de OOP POV es un verdadero problema refactorizar y probar las reglas escritas en un lenguaje declarativo mientras estás refactorizando el código que las afecta.
2. A menudo, siempre debemos pensar en el orden de ejecución de las reglas que se convierten en un desastre cuando hay muchas de ellas.
3. 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 por adelantado.
4. Las reglas que mutan los objetos utilizados en otros también aumentan la complejidad, lo que hace que los desarrolladores los dividan en etapas.