¿Aplicaciones “basadas en reglas” altamente escalables y dinámicas?

Para una aplicación empresarial grande, todos saben que poder adaptarse al cambio es uno de los aspectos más importantes del diseño. Utilizo un enfoque basado en reglas la mayor parte del tiempo para lidiar con la lógica comercial cambiante, con cada regla almacenada en una base de datos. Esto permite realizar cambios fáciles sin sumergirse en detalles desagradables. Ahora, dado que C # no puede evaluar ("foo (bar);") esto se logra utilizando cadenas formateadas almacenadas en filas que luego se procesan en JavaScript en tiempo de ejecución. Esto funciona bien, sin embargo, es menos que elegante, y no sería lo más agradable para que nadie más lo tome una vez que se convierta en legado.

¿Hay una solución más elegante para esto? Cuando entras en miles de reglas que cambian con bastante frecuencia, se convierte en un verdadero oso, pero esto no puede ser un problema tan poco común que alguien no haya pensado en una mejor manera de hacerlo. ¿Alguna sugerencia? ¿Es este método actual defendible? Cuales son las alternativas?

Editar: solo para aclarar, esta es una aplicación empresarial grande, por lo que no importa qué solución funcione, habrá muchas personas que mantendrán constantemente sus reglas y datos (alrededor de 10). Además, los datos cambian con la frecuencia suficiente como para decir que algún tipo de sistema de servidor centralizado es básicamente imprescindible.

Usaría WF o Drools si está tratando de crear una abstracción con la que los no programadores puedan trabajar para desarrollar reglas comerciales. Sin embargo, si se trata de programadores que la abstracción de WF no vale el tiempo que lleva desarrollar una solución, no veo el valor agregado de su inversión.

Una base de datos es una buena manera de mantener reglas que pueden cambiar mucho, pero permítanme sugerir una posible alternativa (no necesariamente mejor, sino una alternativa).

1) Separe la lógica de negocios en su propia capa (dll), abstrayendo cómo la está llamando con algunas interfaces (observe la estrategia y los patrones de observación), es decir, IRuleEvaluator.Evaluate (string myParams).

2) Ahora puede crear clases discretas para cada regla (si es necesario) y las pruebas unitarias adjuntas.

3) Ahora para la Pièce de résistance, conecte todo detrás de escena en un contenedor de COI: el dll y la instancia del evaluador de reglas en sí. De esta manera, su evaluador de reglas se construye a través de la configuración en tiempo de ejecución: nada está codificado en conjunto.

Este enfoque es muy dinámico (quizás demasiado dinámico para algunos gustos): le permitirá tener pruebas unitarias discretas reales para todas sus reglas. Si necesita volver a implementar o cambiar una regla, puede descartar una nueva DLL, cambiar su archivo de configuración de IOC, reiniciar y verificar, o revertir el cambio si algo está mal, sin modificar su código central (como un base de datos). Y a diferencia de una base de datos, mantendrá la lógica y el código de la aplicación bajo un paraguas, en lugar de la mitad escrita en C # y la otra mitad en SQL.

Hay dos casos de reglas que he visto. En la mayoría de los casos, la regla en sí no es muy volátil (casi fija), pero los usuarios comerciales pueden cambiar los datos sobre los que se toma la decisión. En este caso, los patrones de diseño simples para encapsular cada regla con la lectura de los datos de referencia de DataBase suelen ser suficientes. Luego, proporcione una interfaz para cambiar los datos de referencia de las reglas.

Los otros casos en que la lógica de la regla en sí se puede cambiar dinámicamente. Un enfoque sería utilizar IronPython u otros lenguajes dinámicos (en .Net 4) para implementar las reglas y cargarlas dinámicamente en el momento de la ejecución. Esto es un compromiso ya que aún requerirá que los programadores cambien las reglas.

Si realmente desea que las reglas sean editables por los usuarios comerciales, crear DSL para su dominio comercial es un enfoque a seguir. Sin embargo, esta es una empresa compleja.

Finalmente, usar Workflow o BizTalk puede ayudar si las reglas se ajustan a los patrones de transformación / orquestación.

Si está diseñando una aplicación "basada en reglas" altamente escalable donde las reglas están sujetas a cambios frecuentes de la empresa, considere los productos BRMS líderes del mercado, tales como: 1. IBM WODM 2. Asesor FICO BLAZE 3. Drools (código abierto)

He estado trabajando en grandes aplicaciones comerciales con un enfoque BRMS que las hace altamente escalables y fáciles de mantener, y también las hace muy flexibles con CERO tiempo de inactividad para la producción. Hace feliz a los negocios. :)

Supongo que no se refería estrictamente a las operaciones del lado del cliente y está en .Net desde que mencionó c # ...

Si está en el marco 4, tiene el DLR (tiempo de ejecución del lenguaje dinámico) o en cualquier marco si está almacenando las reglas en sql, también podría procesarlas allí o siempre podría usar linq dinámico en los marcos> 3 o escribir las diferentes funciones como ensamblajes que se pueden cargar por nombre en tiempo de ejecución a través de una carga de ensamblaje.

No todos son elegantes en muchos casos, pero he tenido que usarlos todos a veces.

Una cosa que me viene a la mente es Windows Workflow Foundation , que se puede usar junto con ASP.NET pero se ejecutaría en el lado del servidor (por lo que puede no ser aplicable a lo que está haciendo). En Java land hay jBPM (gestión de procesos de negocio) que también se ejecuta en el lado del servidor.

Dado que esas soluciones probablemente no se ajusten a sus necesidades , lo mejor que puede hacer es implementar esas reglas comerciales en código antiguo (usando javascript, C # o lo que sea mejor para el trabajo) y esperar que el código de programación sea tiene que actualizarse cuando ocurren cambios de diseño. El uso de patrones de diseño orientados a objetos hará que el código sea fácilmente extensible. Si escribe bien el código, el esfuerzo necesario para cambiarlo en el futuro debería ser mínimo.

Si tus reglas son todas de una forma

if <condition>
then <action>
[else <action]

Puede usar Drools.NET u otra implementación de Rete como iLog.