Skip navigation

En  Give Your Business Logic a Framework with Drools se encuentra un buen ejemplo:

        if ((user.isMemberOf(AdministratorGroup) && user.isMemberOf(teleworkerGroup)) ||
                user.isSuperUser() {
            // more checks for specific cases
            if ((expenseRequest.code().equals("B203") ||
                    (expenseRequest.code().equals("A903") && (totalExpenses < 200) &&
                            (bossSignOff > totalExpenses)) && (deptBudget.notExceeded)) {
                // issue payments
            }
            else if {
                // check lots of other conditions
            }
        }
        else {
            // even more business logic
        }
    }

Este extracto de código muestra que las reglas son difíciles de programar y mantener en Java. Un problema potencial puede ser la frecuencia de cambio de las reglas, para este ejemplo, que los roles y los códigos cambien frecuentemente. Para aplicar un cambio de esta clase implica por lo menos modificar el código, compilar e instalar la aplicación, pudiendo llevar horas o días. Una forma de evitar este proceso es tener separadas las reglas de negocio del código y una manera efectiva de hacerlo es utilizando un motor de reglas.

En su forma más simple, un motor de reglas de negocio está compuesto de tres elementos: un conjunto de reglas, la base de conocimientos (conocida como área de trabajo) y el procesador de reglas. Las reglas son sentencias de la forma IF-THEN, de tal manera que si se cumplen todas las condiciones del IF se ejecutan todas las acciones del THEN. El motor utilizará la base de conocimientos para decidir que reglas deben activarse.
El criterio de decisión para la utilización de un motor de reglas podría ser:

  • Complejidad moderada o alta de las reglas de negocio
  • Las reglas de negocio no son estáticas y se prevee que cambien continuamente
  • Costos asociados. ¿Puede el proyecto soportar los costos de la incorporación de un motor de reglas? Hay diversos costos relacionados: evaluación de productos, licencias, curva de aprendizaje, etc.

Otros usos de los motores de reglas:

  1. Como herramienta de simulación y pruebas de concepto
  2. Como parte de la metodología para recopilar, documentar y mantener las reglas de negocio ya que proporciona una manera flexible de irlas incorporando.

Dependiendo de la sofisticación de las reglas, puede no ser factible incorporar o modificar reglas “en vivo” sin pasar por un periodo de pruebas de la aplicación. Martin Fowler en Should I use a Rules Engine? lo describe muy bien:

Often the central pitch for a rules engine is that it will allow the business people to specify the rules themselves, so they can build the rules without involving programmers. As so often, this can sound plausible but rarely works out in practice.

The basic idea of production rules is very simple. In order to keep the implicit behavior under control you also need to limit the number of rules by keeping the rules within a narrow context.

2 Comments

  1. Te falta mencionar que es paradojico que las unicas organizaciones que deberian de mantener un engine de reglas son las que han llegado a una madurez en sus procesos ( han cambiado sus procesos hasta encontrar los mas optimos y continuar cambiandolos () ) y que ahora las pretenden automatizar mas no las empresas que no poseen reglas y creen que con un engine de reglas mejoraran procesos que ni siquiera estan definidos o que siquiera existen (ni siquiera han delimitado el contexto como indicas =>by keeping the rules within a narrow context).

  2. En cuanto a la pregunta de si los motores de reglas permiten realmente que los usuarios de negocio definan reglas, habría que matizar la diferencia entre motor de reglas y BRMS (Business Rules Management System).

    Muchos motores de reglas se han puesto la etiqueta BRMS pero realmente no lo son. Siguen estando orientado a técnicos y no cubren todo el ciclo de vida de las reglas, solo la definición, la ejecución y poco más.

    José Gabriel García.
    CEO en Delta-R


Leave a comment