¿Cómo afecta el uso de un motor de reglas al diseño, implementación y rendimiento de una aplicación?

Estoy interesado en la capacidad de los motores de reglas para:

• lanzar e iterar sobre la lógica impulsada por el negocio
• hacer que los "usuarios comerciales" realicen la modificación real de esas reglas en lugar de los desarrolladores
• comprender las reglas comerciales en general

Además, ¿el uso de un motor de reglas afecta la calidad de una aplicación?

¿Cambia el uso de un motor de reglas si estaba implementando una configuración de 1 máquina frente a su arquitectura frente a una arquitectura distribuida basada en la nube de varios niveles que utiliza miles de máquinas? ¿Cómo sería diferente?

La decisión de exponer una interfaz para que el personal no técnico modifique las reglas comerciales depende en gran medida de varios factores, incluidos los objetivos del proyecto, el costo del proyecto, la vida útil del proyecto y la proporción de conocimientos a incógnitas en el proyecto.

Por ejemplo, si creyera que nadie usaría la interfaz de reglas, entonces probablemente optaría por no implementarla. Sin embargo, si tuviera razones para creer que los cambios serían frecuentes y que diferentes usuarios finales esperarían que se establecieran diferentes reglas, entonces consideraría trabajar en la creación de dicha funcionalidad.

Elegí hacer esto en un proyecto, y pasaron años antes de que la función fuera ampliamente utilizada. Sospeché que eventualmente tendríamos usuarios finales que querrían personalizar las cosas ellos mismos, por lo que implementamos esta funcionalidad en partes.

Comenzó como algo que solo ciertas personas, como los desarrolladores o administradores, podrían usar. La interfaz era torpe, pero utilizable si sabía lo que estaba haciendo. Pero cuando el producto estaba a punto de completarse, la lógica del motor de reglas era útil y nuestro equipo de diseño le brindó una hermosa interfaz de usuario orientada al cliente.

Si tuviera que hacerlo diferente, podría elegir una arquitectura de base de datos diferente solo porque la curva de aprendizaje es alta. Pero en resumen, construirlo desde el principio llevó a muchas características de cara al cliente más adelante sin los dolores de cabeza de tener que volver al código y refactorizarlo para incluir todas las reglas dinámicas.

Si tuviera que hacer esto, crearía un lenguaje específico de dominio para expresar las reglas, y tal vez le daría a los tipos de negocio una interfaz de usuario para modificarlo si se solicita. Luego use un lenguaje funcional (como Haskell, Lisp o Erlang) para evaluar las reglas.

Si se requiriera un paralelismo masivo, iría con Erlang, que hace muy bien la concurrencia. Usar Erlang se escalaría bien de 1 nodo a 100 o más.

Si piensa en las reglas como un álgebra que se aplicará a un conjunto de datos, será mucho más fácil descifrar lo que necesita en su código y probarse a sí mismo (o a sus gerentes) que es correcto. Este es uno de esos lugares donde un lenguaje funcional funcionará a tu favor.

Escribí una aplicación basada en WF (Windows Workflow Foundation). Mi jefe (un DBA) estaba convencido de que WF podría realizar subprocesos múltiples sin la necesidad de planificar la concurrencia. La memoria se dividió a fondo, pero hubo tantos problemas que no puedo explicarlo en solo unos pocos párrafos y está solo ligeramente relacionado con su pregunta ... así que continúo.

Capacidad para iterar BL:
WF hace esto bien.
Permitir a los no técnicos "construir una aplicación":
WF hace esto bien SI la arquitectura funciona Y los no técnicos entienden las limitaciones técnicas ... La nuestra no.
Capacidad para comprender las reglas comerciales en general:
hay algunos complementos que pueden hacer algunas cosas básicas, como sharepoint puede automatizar los flujos de trabajo. No me metí en estos artículos.
Calidad de lanzamientos de software:
Mediocre. WF no funcionó bien para nuestros propósitos, pero el sistema estaba mal diseñado y mis manos estaban atadas.
Velocidad de aplicaciones:
Lento. La curva de aprendizaje es bastante empinada para desarrolladores y usuarios finales por igual. La forma en que WF separó la memoria (dominios de aplicación, si mal no recuerdo) hizo que la comunicación entre hilos, mutexes y otros conceptos de subprocesamiento no fueran correctos o simplemente no funcionaran.

Finalmente, escribí un prototipo para probar que WF falla en la forma en que se implementó. Lo reemplacé con multihilo común. El rendimiento y la legibilidad del código aumentaron. Tome esto con un grano de sal, ya que esta fue mi primera aplicación profesional de WF.

Los no técnicos pueden llegar a creer que prácticamente todo es posible sin la necesidad de un programador, un negativo potencialmente grande para todo el "dummy down" de BL; Los problemas sociológicos relacionados con esto mataron el proyecto.

Si pudiera regresar y hacerlo a mi manera : use el enhebrado tradicional y el moldeado BL logrado a través del Patrón Decorador. Escribí una prueba de concepto que utilizaba estas tecnologías y funcionó bien. Y el mapeo BL debe estar envuelto en una IU SIMPLE.
Actualización
Encontré una publicación anterior que escribí al resolver problemas de concurrencia. El código muestra cómo imprimir "hello world" en flujos de trabajo paralelos no funciona sin comprender lo que sucede debajo de las cubiertas (lo que anula el propósito de la abstracción WF). El moderador de MSDN explica una descripción general de alto nivel de cómo las actividades paralelas son realmente secuenciales. Concluye básicamente con "necesitas leer todo el manual" para hacer algo tan básico. http://social.msdn.microsoft.com/Forums/en/windowsworkflowfoundation/thread/8a1fa165-ad5c-4cd2-b489-7ea5fc31fed8

Buena suerte.

He tenido una experiencia menos que perfecta al conectarme desde un código Java a un motor de reglas de Oracle. Algo de esto puede deberse a la falta de experiencia por parte de los autores de las reglas, pero esto es lo que enfrenté.

• Implementamos nuestro motor de reglas como un dispositivo sin estado. La persona que llamó tuvo que reunir todos los parámetros y pasarlos al motor para su evaluación. Esto significaba que si la regla necesitaba otro campo de datos, todos los clientes debían actualizarse. Esto negaba la ventaja promocionada de poder actualizar las reglas independientemente de sus consumidores.
• El motor publicó un SOAP WSDL, pero se generó automáticamente a partir del conjunto de reglas. Pequeños cambios a las reglas romperían el contrato con los consumidores.
• El motor fue bueno para evaluar las reglas, pero terrible para decirnos por qué falló la evaluación. Fue difícil enviar mensajes de error informativos al usuario.
• El WSDL no era apto para el consumo general. El conjunto de reglas más simple tenía un WSDL de 14 páginas, que expuso los elementos internos de la base de reglas. Tuvimos que poner una capa de traducción SOA al frente para presentar una fachada amigable para los negocios. Entonces, en lugar de llamar a una biblioteca local 100% confiable, había dos servidores adicionales en el bucle. Eso no agrega confiabilidad en lo más mínimo. Además, cualquier cambio en la firma de la regla involucraba tres equipos dispares que actualizaban el código. ¡No es mi definición de ágil!
• Cada vez que el conjunto de reglas necesitaba adiciones, el WSDL tendría que actualizarse, lo que significaba que los clientes ya no lo entendían. Esto condujo a la adición de nuevos puntos finales SOAP para v2, v3 ... que tuvieron efectos secundarios de la necesidad de actualizar las reglas del firewall.
• Las reglas se expresaron en "inglés estructurado", que era fácilmente comprensible para reglas simples, pero casi opaco para reglas complejas.
• Nunca pudimos encontrar contratistas que conocieran el lenguaje de autoría de las reglas.
• El lenguaje de reglas no implementó matrices, recursividad u orientación a objetos. En un caso, la única forma de implementar una regla era mediante una llamada a una hoja de cálculo de Excel, donde la regla se implementó en VB. ¿Por qué molestarse?

No creo que la elección de usar un motor de reglas (o no) sea clara. Le sugiero que realice un prototipo de cualquier motor que desee utilizar, luego tome una decisión informada. Ciertamente no son una bala de plata ...