¿Cuándo NO debería utilizar un motor de reglas? [cerrado]

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 debería usar un motor de reglas

Lo mejor que tengo hasta ahora es esto:

Los motores de reglas no están diseñados para manejar flujos de trabajo o ejecuciones de procesos, ni tampoco están diseñados para ejecutar reglas.

¿Alguna otra gran razón por la que no debería usarlos?

Me pongo muy nervioso cuando veo que la gente usa conjuntos de reglas muy grandes (por ejemplo, del orden de miles de reglas en un solo conjunto de reglas). Esto sucede a menudo cuando el motor de reglas es un singleton ubicado en el centro de la empresa con la esperanza de que mantener las reglas DRY las haga accesibles para muchas aplicaciones que las requieren. Desafiaría a cualquiera a que me dijera que un motor de reglas de Rete con tantas reglas se entiende bien. No conozco ninguna herramienta que pueda verificar para garantizar que no existan conflictos.

Creo que dividir los conjuntos de reglas para mantenerlos pequeños es una mejor opción. Los aspectos pueden ser una forma de compartir un conjunto de reglas común entre muchos objetos.

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

Daré 2 ejemplos de mi experiencia personal en los que usar un motor de reglas fue una mala idea, tal vez eso ayude:

1. En un proyecto anterior, noté que los archivos de reglas (el proyecto usaba Drools) contenían una gran cantidad de código Java, incluidos bucles, funciones, etc. Eran esencialmente archivos Java disfrazados de archivos de reglas. Cuando le pregunté al arquitecto sobre su razonamiento para el diseño, me dijeron que "las reglas nunca fueron diseñadas para que las mantuvieran los usuarios comerciales".

Lección : Se denominan "Reglas comerciales" por una razón, no utilice reglas cuando no pueda diseñar un sistema que los usuarios comerciales puedan mantener / entender fácilmente.

2. Otro caso; El proyecto usó reglas porque los requisitos estaban mal definidos / entendidos y cambiaban con frecuencia. La solución del equipo de desarrollo fue utilizar reglas de manera extensiva para evitar implementaciones frecuentes de código.

Lección : Los requisitos tienden a cambiar mucho durante los cambios de la versión inicial y no justifican el uso de reglas. Utilice reglas cuando su negocio cambie con frecuencia (no requisitos). Por ejemplo: - Un software que hace sus impuestos cambiará cada año a medida que cambien las leyes tributarias 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 utilice reglas como alternativa a la implementación de código.

Soy un gran admirador de los motores de reglas comerciales, ya que pueden 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 almacén de datos fue encontrar procedimientos almacenados que contienen estructuras CASE complicadas que se extienden por páginas enteras. Fue una pesadilla depurar, ya que era muy difícil entender la lógica aplicada en estructuras CASE tan largas y determinar si hay una superposición entre una regla en la página 1 del código y otra de la página 5. En general, tuvimos más de 300 de estas 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, supe que algo tenía que cambiar. En aquel entonces estuve trabajando en un prototipo que luego se convirtió en el padre de lo que ahora es un motor de reglas comerciales personalizadas, capaz de manejar todos los operadores estándar SQL. Inicialmente usamos Excel como herramienta de autoría y, posteriormente, creamos una aplicación ASP.net que permitirá a los Usuarios Comerciales definir sus propias reglas comerciales, sin 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 contable. No creo que tal escenario hubiera sido posible con solo codificarlo.

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

• Necesita tener usuarios empresariales capaces que tengan un excelente conocimiento del negocio de la empresa.
• 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 traducirse en reglas para ser manejadas por un motor de reglas de negocios. También hemos tenido que cuidar que estas plantillas iniciales sean completamente comprensibles para los usuarios comerciales.
• Debe tener una aplicación utilizada para la creación de reglas, en la que se implementen algoritmos para la detección de reglas comerciales superpuestas. De lo contrario, terminará con un gran lío, donde ya nadie entenderá los resultados que obtienen. Cuando tiene un error en un componente genérico como un motor de reglas de negocio personalizado, puede ser muy difícil depurarlo e involucrar pruebas exhaustivas para asegurarse de que las cosas que funcionaban antes también funcionan 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 motor de reglas de negocio es que permite a los usuarios recuperar el control sobre las definiciones y la creación de las reglas de negocio, sin la necesidad de acudir al departamento de TI cada vez que necesitan modificar algo. También reduce la carga de trabajo de los equipos de desarrollo de TI, que ahora pueden centrarse en crear cosas con más valor añadido.

Salud,

Nicolae

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

poner la lógica en manos de personal no técnico

He visto que esto funciona muy bien, 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 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.

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.

GRAN artículo sobre cuándo no usar un motor de reglas ... (así como cuándo usar uno) ....

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, crear una interfaz maravillosa y hacer que los desarrolladores escriban e implementen estas nuevas reglas. La ventaja es que es tremendamente rápido porque normalmente pasaría la sesión de hibernación O la sesión jdbc así como cualquier parámetro para que tenga acceso a todos los datos de sus aplicaciones pero de una manera eficiente. Con una lista de hechos, puede haber muchos bucles / coincidencias que realmente pueden ralentizar el sistema ... Es otra forma de evitar un motor de reglas y poder implementarse dinámicamente (sí, nuestras reglas geniales se implementaron en un base de datos y no tuvimos recursividad ... o cumplió con la regla o no). Es sólo otra opción ... ah, y un beneficio más es no aprender la sintaxis de las reglas para los desarrolladores entrantes.

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 querer 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 en su lugar ... igual de dinámico y los nuevos desarrolladores que se unen a su equipo pueden aprenderlo más rápido que el lenguaje drools (pero esa es mi opinión)

En mi experiencia, los motores de reglas funcionan mejor cuando se cumple lo siguiente:

1. Doctrina bien definida para su dominio de problemas
2. Datos de alta calidad (preferiblemente automatizados) para ayudar a impulsar la mayoría de sus entradas
3. Acceso a expertos en la materia
4. Desarrolladores de software con experiencia en la creación de sistemas expertos.

Si falta alguno de estos cuatro rasgos, es posible que aún encuentre un motor de reglas que funcione para usted, pero cada vez que lo probé y me faltaba 1, me encontré con problemas.

Sin duda es un buen comienzo. La otra cosa con los motores de reglas es que algunas cosas se entienden bien, son deterministas y sencillas. La retención de nómina es (o solía ser) así. Usted podría expresarla como reglas que ser resueltas por un motor de reglas, pero se podía expresar las mismas reglas que una mesa bastante sencilla de valores.

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

Los motores de reglas son buenos cuando tiene bases de conocimientos complicadas y necesita una búsqueda. Los motores de reglas pueden resolver problemas complicados y se pueden adaptar rápidamente a situaciones cambiantes, pero imponen mucha complejidad a la implementación básica.

Muchos algoritmos de decisión son lo suficientemente simples como para expresarse como un programa simple basado en tablas sin la complejidad que implica un motor de reglas real.

Recomendaría encarecidamente motores de reglas comerciales como Drools como código abierto o motor de reglas comerciales como LiveRules.

• Cuando tiene muchas políticas comerciales que son de naturaleza volátil, 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 donde los cambios son inevitables de forma regular.

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

Para mí, como gente que acaba de tocar BRE, el beneficio de BRE se denomina así para permitir que el sistema se adapte al cambio empresarial, por lo que se centra en la adaptación al cambio.
¿Importa si la regla establecida en el momento x es diferente de la regla establecida en el momento y debido a:
a) los empresarios no entienden los negocios, o;
b) los empresarios no entienden las reglas?