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

Question

Para una gran aplicación empresarial, 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 el cambio de la lógica comercial, y cada regla se almacena en un DB. Esto permite que se realicen cambios fáciles sin sumergirse en detalles desagradables. Ahora, dado que C# no puede evaluar ("foo (bar);"), esto se logra mediante el uso de 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 el más agradable para que nadie más se retire una vez que se vuelva 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 oso real, pero esto no puede ser tan poco común que alguien no haya pensado en una mejor manera de hacerlo. ¿Alguna sugerencia? ¿Es este método actual defendible? ¿Cuáles son las alternativas?

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

Answer 1

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

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

1) Separe la lógica del negocio en su propia capa (DLL): abstrae cómo lo llama con algunas interfaces (mire la estrategia y los patrones de observador), es decir, iruleevaluator.evaluate (String myParams).

2) Ahora puede crear clases discretas para cada regla (si es necesario) y las pruebas unitarias que lo acompañan.

3) Ahora para la pièce de resistencia, 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 juntos.

Este enfoque es muy dinámico (tal vez 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 soltar un nuevo DLL, cambiar su archivo de configuración del IOC, reiniciar y verificar, o volver a revertir el cambio si algo está mal, sin modificar su código central (al igual que un base de datos). Y a diferencia de una base de datos, mantendrá la lógica y el código de aplicación bajo un paraguas, en lugar de la mitad escrita en C# y la mitad en SQL.

Answer 2

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 datos de los negocios pueden cambiar los datos sobre la decisión pueden cambiar. En este caso, los patrones de diseño simples para encapsular cada regla al leer los datos de referencia de la base de datos suelen ser suficientes. Luego proporcione un frontend para cambiar los datos de referencia de reglas.

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

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

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

Answer 3

Si está diseñando una aplicación "basada en reglas" altamente escalable donde las reglas están sujetas a cambios frecuentes del negocio, considere productos BRMS líderes en el mercado como: 1. IBM WODM 2. FICO Blaze Advisor 3. Babeas (código abierto)

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

Answer 4

Supongo que no se refirió estrictamente a las operaciones del lado del cliente y está en .NET ya que mencionó C#...

Si está en Framework 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 puede procesarlas allí o siempre puede usar Linq dinámico en los marcos> 3 o escribir las diferentes funciones como ensamblajes que se pueden cargar por nombre a 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.

Answer 5

Una cosa que 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 negocios) que también se ejecuta en el lado del servidor.

Dado que esas soluciones probablemente no se ajustarían a la factura, lo mejor que puede hacer puede 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 tenga que actualizarse cuando ocurran los cambios de diseño. El uso de patrones de diseño orientados a objetos hará que el código se pueda extender fácilmente. Si escribe bien el código, el esfuerzo necesario para cambiarlo en el futuro debería ser mínimo.

Answer 6

Si sus reglas son todas de forma

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

Puede usar dRools.net u otra implementación de Rete como ILOG.