rule-engine - reglas - open rules

¿Cuándo NO deberías usar un motor de reglas? (11)

Tengo una lista bastante decente de las ventajas de usar un motor de reglas, así como algunas razones para usarlas, lo que necesito es una lista de las razones por las que NO debes usar un motor de reglas.

Lo mejor que tengo hasta ahora es esto:

Los motores de reglas en realidad no están diseñados para manejar el flujo de trabajo o las ejecuciones de procesos, ni tampoco son motores de flujo de trabajo o herramientas de administración de procesos diseñados para hacer reglas.

¿Alguna otra razón importante por la que no deberías usarlos?

Daré 2 ejemplos de la experiencia personal donde el uso de un motor de reglas fue una mala idea, tal vez eso ayude:

En un proyecto anterior, noté que los archivos de reglas (el proyecto usaba Drools) contenían una gran cantidad de código java, incluyendo bucles, funciones, etc. Eran esencialmente archivos java disfrazados como archivo de reglas. Cuando le pregunté al arquitecto sobre su razonamiento para el diseño, me dijeron que las "Reglas nunca debían ser mantenidas por usuarios comerciales".

Lección : Se llaman "Reglas comerciales" por alguna razón, no use reglas cuando no pueda diseñar un sistema que los usuarios de negocios puedan mantener o comprender fácilmente.

Otro caso; El proyecto usaba reglas porque los requisitos se definían / entendían mal y se cambiaban con frecuencia. La solución del equipo de desarrollo fue utilizar reglas extensamente para evitar despliegues frecuentes de código.

Lección : los requisitos tienden a cambiar mucho durante los cambios de lanzamiento inicial y no garantizan el uso de las reglas. Use reglas cuando su empresa cambie a menudo (no requisitos). Por ejemplo: un software que paga sus impuestos cambia cada año a medida que cambian las leyes impositivas y el uso de las reglas es una excelente idea. La versión 1.0 de una aplicación web cambiará a menudo a medida que los usuarios identifiquen nuevos requisitos, pero se estabilizarán con el tiempo. No use reglas como alternativa al despliegue del código. 1.

EXCELENTE artículo sobre cuándo no usar un motor de reglas ... (y cuándo usarlo) ...

http://www.jessrules.com/guidelines.shtml

Otra opción es si tiene un conjunto lineal de reglas que solo se aplican una vez en cualquier orden para obtener un resultado, es crear una interfaz maravillosa y hacer que los desarrolladores escriban y desplieguen estas nuevas reglas. La ventaja es que es perversamente rápido porque normalmente pasaría la sesión de hibernación O la sesión jdbc, así como también cualquier parámetro para que tenga acceso a todos sus datos de aplicaciones, pero de manera eficiente. Con una lista de hechos, puede haber una gran cantidad de bucles / coincidencias que realmente pueden ralentizar el sistema ..... Es otra forma de evitar un motor de reglas y ser capaz de implementarse dinámicamente (sí, nuestras reglas geniales se implementaron en una base de datos y no tuvimos recursión ... cumplió con la regla o no). Es solo otra opción ... oh, y una ventaja más no es aprender la sintaxis de las reglas para los desarrolladores entrantes. Tienen que aprender algo maravilloso, pero eso está muy cerca de Java, por lo que la curva de aprendizaje es mucho mejor.

Realmente depende de tu contexto. El motor de reglas tiene su lugar y lo anterior es solo otra opción si tiene reglas en un proyecto que puede implementar dinámicamente para situaciones muy simplificadas que no requieren un motor de reglas.

BÁSICAMENTE NO use un motor de reglas si tiene un conjunto de reglas simple y puede tener una interfaz maravillosa ... igual de desplegable dinámicamente y los nuevos desarrolladores que se unan a su equipo pueden aprenderlo más rápido que el lenguaje drools. (Pero esa es mi opinión)

El único poit que he notado que es "la espada de doble filo" es:

colocando la lógica en manos del personal no técnico

He visto este trabajo genial, cuando tienes uno o dos genios multidisciplinarios en el lado no técnico, pero también he visto la falta de tecnicidad que conduce a la hinchazón, más errores, y en general 4 veces el costo de desarrollo / mantenimiento.

Por lo tanto, debe considerar seriamente su base de usuarios.

En mi experiencia, los motores de reglas funcionan mejor cuando los siguientes son verdaderos:

Doctrina bien definida para su dominio problemático
Datos de alta calidad (preferiblemente automatizados) para ayudar a conducir la mayoría de sus entradas
Acceso a expertos en la materia
Desarrolladores de software con experiencia creando sistemas expertos

Si falta alguno de estos cuatro rasgos, aún puede encontrar un motor de reglas que funcione para usted, pero cada vez que lo he probado con 1 falta, me he encontrado con problemas.

Eso es ciertamente un buen comienzo. La otra cosa con los motores de reglas es que algunas cosas son bien entendidas, deterministas y directas. La retención de la nómina es (o solía ser) así. Podría expresarlo como reglas que serían resueltas por un motor de reglas, pero podría expresar las mismas reglas que una tabla de valores bastante simple.

Por lo tanto, los motores de flujo de trabajo son buenos cuando se expresa un proceso a más largo plazo que tendrá datos persistentes. Los motores de reglas pueden hacer algo similar, pero hay que agregar mucha complejidad añadida.

Los motores de reglas son buenos cuando tienes bases de conocimiento complicadas y necesitas buscar. Los motores de reglas pueden resolver problemas complicados y pueden adaptarse rápidamente a situaciones cambiantes, pero imponen una gran complejidad en la implementación básica.

Muchos algoritmos de decisión son lo suficientemente simples como para expresarlos como un simple programa basado en tablas sin la complejidad implícita en un motor de reglas real.

Me pongo muy nervioso cuando veo personas que usan conjuntos de reglas muy grandes (por ejemplo, del orden de miles de reglas en un solo conjunto de reglas). Esto ocurre a menudo cuando el motor de reglas es un singleton ubicado en el centro de la empresa con la esperanza de que al mantener las reglas DRY pueda acceder a muchas aplicaciones que lo requieran. Desafiaría a cualquiera para decirme que un motor de reglas Rete con tantas reglas es bien entendido. No estoy al tanto de ninguna herramienta que pueda verificar para asegurar que los conflictos no existan.

Creo que las reglas de partición para mantenerlos pequeños es una mejor opción. Los aspectos pueden ser una forma de compartir un conjunto de reglas comunes entre muchos objetos.

Prefiero un enfoque más simple, más basado en datos siempre que sea posible.

Pensé que el artículo de Alex Papadimoulis era bastante revelador: http://thedailywtf.com/articles/soft_coding.aspx

No es exhaustivo, pero tiene algunos puntos buenos.

Publiqué sobre esto hace un tiempo.

Puede verificarlo aquí -> http://www.codetoglory.com/?p=21

Deberías usarlo realmente cuando tienes reglas dinámicas que cambian constantemente como Seguros, comercio y dominios de divisas.

Espero que mi artículo de blog pueda darle una buena visión general.

Realmente no entiendo algunos puntos como:
a) la gente de negocios necesita entender muy bien el negocio, o;
b) desacuerdo sobre la gente de negocios no necesita saber la regla.

Para mí, como personas que solo tocan BRE, el beneficio de BRE se llama para permitir que el sistema se adapte al cambio comercial, por lo tanto, se centra en la adaptación del cambio.
¿Importa si la regla establecida en el tiempo x es diferente de la regla establecida en el tiempo y debido a:
a) la gente de negocios no entiende los negocios, o;
b) la gente de negocios no entiende las reglas?

Recomiendo encarecidamente motores de reglas de negocio como Drools como código abierto o motor de reglas comerciales como LiveRules.

Cuando tiene muchas políticas comerciales que son volátiles por naturaleza, es muy difícil mantener esa parte del código de tecnología central.
El motor de reglas proporciona una gran flexibilidad del marco y es fácil de cambiar e implementar.
Los motores de reglas no deben usarse en todas partes, pero deben usarse cuando hay muchas políticas en las que los cambios son inevitables de forma regular.

Soy un gran admirador de Business Rules Engines, ya que puede ayudarte a hacer tu vida mucho más fácil como programador. Una de las primeras experiencias que tuve mientras trabajaba en un proyecto de Data Warehouse fue encontrar procedimientos almacenados que contengan complicadas estructuras CASE que abarcan páginas enteras. Fue una pesadilla para depurar, ya que era muy difícil comprender la lógica aplicada en estructuras de CASE tan largas, y para determinar si hay una superposición entre una regla en la página 1 del código y otra desde la página 5. En general, tuvimos más de 300 de esas reglas integradas en el código.

Cuando recibimos un nuevo requisito de desarrollo, para algo llamado Destino de Contabilidad, que implicaba tratar más de 3000 reglas, sabía que algo tenía que cambiar. En aquel entonces, he estado trabajando en un prototipo que más adelante se convertirá en el padre de lo que ahora es un motor de reglas de negocios personalizados, capaz de manejar todos los operadores estándar de SQL. Inicialmente, utilizamos Excel como herramienta de creación y, más adelante, hemos creado una aplicación ASP.net que permitirá a los usuarios empresariales definir sus propias reglas comerciales, sin la necesidad de escribir código. Ahora el sistema funciona bien, con muy pocos errores y contiene más de 7000 reglas para calcular este Destino de Contabilidad. No creo que ese escenario hubiera sido posible solo por una codificación difícil. Y los usuarios están muy contentos de que puedan definir sus propias reglas sin que las TI se conviertan en su cuello de botella.

Aún así, hay límites para tal enfoque:

Necesita tener usuarios comerciales capaces que tengan una excelente comprensión del negocio de la compañía.
Existe una carga de trabajo significativa en la búsqueda de todo el sistema (en nuestro caso, un Almacén de Datos), con el fin de determinar todas las condiciones codificadas que tienen sentido para traducir en reglas que serán manejadas por un Motor de reglas de negocio. También hemos tenido que cuidar que estas plantillas iniciales sean totalmente comprensibles para los usuarios comerciales.
Debe tener una aplicación utilizada para la creación de reglas, en la que se implementan algoritmos para la detección de reglas empresariales superpuestas. De lo contrario, terminarás con un gran lío, donde ya nadie entiende los resultados que obtienen. Cuando tiene un error en un componente genérico como un Motor de reglas de negocios personalizado, puede ser muy difícil de depurar e involucrar pruebas exhaustivas para asegurarse de que las cosas que funcionaron antes también funcionen ahora.

Se pueden encontrar más detalles sobre este tema en una publicación que escribí: http://dwhbp.com/post/2011/10/30/Implementing-a-Business-Rule-Engine.aspx

En general, la mayor ventaja de utilizar un Business Rule Engines es que permite a los usuarios recuperar el control sobre las definiciones y autorizaciones de Rule Business, sin la necesidad de acudir al departamento de TI cada vez que necesitan modificar algo. También reduce la carga de trabajo sobre los equipos de desarrollo de TI, que ahora pueden enfocarse en construir cosas con más valor agregado.

Aclamaciones,

Nicolae