¿Como implementar lógica de negocios?

Lógica de negocio es la parte de los sistemas que se encarga de transformar las reglas de negocio del mundo real en reglas de negocio automatizadas.

Todo nuestro trabajo como ingenieros de software no vale nada si no implementamos las reglas de negocio que la compañía necesita en los sistemas que construimos.

Las reglas de negocio se utilizan en todos los elementos que forman un sistema:
- Una interfaz de usuario permite el ingreso de información, información que se convierte en registros de base de datos de acuerdo a las reglas de negocio.
- Un proceso toma registros de una base de datos los convierte en otros de acuerdo a las reglas de negocio.
- Etc.

Solo conozco dos requerimientos en común acerca de las reglas de negocio: las reglas de negocio deben ser dinámicas y los usuarios necesitarán personalizarlas tanto como puedan.

¿Pero cual es la forma correcta de implementar esas reglas de negocio?

Primero imaginemos una arquitectura, podría ser MVA (El diseño solo es de prueba). En el adaptador integraremos las reglas de negocio, algo así:

Figura 1: MVA + Business Object

Algunos patrones y tecnologías para este propósito que me parecen interesantes son:

• Los patrones de diseño Strategy y Chain of Responsibility, apache implementa el patrón Chain of Responsibility en su librería commons-chain.
• Tablas de decisiones, Drools posee una implementación de esta solución.
• BRMS basado en proposiciones o diagramas, Drools implementa ambas utilizando su propio lenguaje de reglas para la solución basada en proposiciones y BPM para reglas de negocios basadas en diagramas.

Una clase simple

Obviamente en una clase común y corriente se pueden implementar reglas de negocio, el problema es que cada vez que las reglas de negocio cambian hay que re-programar y probablemente recompilar el componente.
Uno de los requerimientos que debemos cumplir es que sea dinámico, una posible solución es un panel de configuración, el problema ahora es el número de variables que tendría tal configuración, como sea llegaremos a perder el control. Y esto solo servirá en una empresa muy pequeña y por un periodo de tiempo corto, con suerte un periodo mediano.
Esta implementación podría estar directamente en la clase BusinessObject que muestra el diagrama de la Figura 1.  

Patrón Strategy

La principal característica de este patrón es que es intercambiable dinámicamente, es posible tener varias implementaciones de un tipo de estrategia, este podría configurarse de acuerdo a lo que el usuario necesita. Imaginando que cada estrategia podría tener su propia configuración podríamos hacerlo mucho mas dinámico que una clase simple. Sería bastante fácil para el usuario seleccionar una estrategia y cambiarle los parámetros.
Una desventaja es que podría crecer el número de implementaciones y también funcionaría solo para empresas pequeñas y por un tiempo corto a mediano. El diagrama de la figura 1 cambiaría a:

Figura 2: MVA + Business Object + Strategy

La figura 2 muestra 4 estrategias, pero pueden haber tantas implementaciones como el negocio lo requiera. Esa cantidad de posibles estrategías podría crecer descontroladamente.

Patrón Chain of Responsibility

Implementar este patrón es un poco mas complejo que implementar el patrón anterior, pero tiene mayor flexibilidad porque se programan los eslabones de la cadena y un usuario puede organizar los eslabones de acuerdo a las necesidades del negocio y asignarle diferentes propiedades dinámicamente.
Los eslabones son componentes considerados atómicos, los eslabones forman una secuencia y por toda la secuencia pasa un token (elemento que entra a un proceso y es transformado) que es modificado por cada eslabón de acuerdo a sus propiedades. Los eslabones pueden ser reutilizados para armar varias cadenas, cada cadena equivale a un comportamiento de lógica diferente.
Una de las implementaciones de este patrón es commons-chain de apache.

Figura 3: MVA + Business Object + Chain of Responsibility

La figura 3 muestra la implementación de una cadena de responsabilidad, los eslabones A, B, C y D pueden generar varias cadenas diferentes dependiendo de las necesidades del negocio.

Por ejemplo un usuario podría usar la cadena A-B-C-D, otro usuario podría utilizar la cadena A-D, etc. 

A pesar de la flexibilidad de este patrón, las cadenas son siempre secuencias y en cualquier caso pasa el token por todos los eslabones, con un poco de imaginación se puede modificar esto y hacer que un eslabón ejecute su lógica de acuerdo a ciertas condiciones que podrían ser configurables.

BRMS o Sistemas de administración de reglas de negocios

son sistemas que permiten programar reglas de negocios en base a matrices, proposiciones o en base a flujos diagramados visualmente, la ventaja de estos sistemas es que las reglas de negocio están centralizadas, están a un nivel sobre la programación codificada y además son dinámicas.

En la arquitectura de la figura 1, solo necesitamos agregarle la comunicación hacia el BRMS y podemos llevar el BRMS a nivel de usuario final y lo suficientemente dinámico.

Figura 4: MVA + Business Object + BRMS

Tablas de decisiones: son tablas o matrices que contienen proposiciones, las proposiciones están distribuídas en las celdas. Generalmente cada fila es una regla. Entre las filas es posible ingresar metadata, como importación de objetos para utilizarlos en las reglas, definición de variables, etc. 
Esta solución está diseñada para un alto número de proposiciones, cuando esas proposiciones varían demasiado y se tiene una acción como resultado de la regla.

Como ejemplo, imaginemos un sistema de telefonía con productos X, Y y Z. Cada producto tiene diferente precio y diferentes promociones dependiendo del día de la semana, del mes, dependiendo cuantos productos ha comprado el cliente, el tipo de cliente, etc. Cuando el cliente recarga su saldo el sistema envía una petición a una matriz de decisiones para saber cuanto le recargará.

Eso se puede almacenar en un objeto con la estructura:

      name: Isaac Newton
      type: A
      product: X
      balance: 0

la variable que contiene estos datos se podría llamar c, también podría existir una variable now que contiene información del tiempo:

proposition	proposition	proposition	action
c.type=='A'	now.day=='Mon'	c.product=='X'	c.balance=c.balance+20
c.type=='B'	true	c.product=='Y'	c.balance=c.balance+15
c.type=='A'	true	c.product=='X'	c.balance=c.balance+13
true	true	true	c.balance=c.balance+10

Para el caso del ejemplo, el balance agregado sería 13 para un día no lunes para los cliente tipo A y 20 para un día lunes y el resto del tiempo cuando se compra cualquier producto se agrega 10 al balance.
En este caso asumimos que es una conjunción de proposiciones, pero existen motores de tablas de decisiones que permiten cualquier asociación de proposiciones.

Basado en proposiciones: son sistemas basados en un lenguaje de programación para proposiciones. Un token es enviado a un intérprete de este lenguaje y este intérprete le aplica las reglas programadas. Generalmente es un lenguaje de programación de alto nivel, estos sistemas cuentan con una sintaxis simple como:

rule "choose price"
when
     c.type=='A' && now.day=='Mon' && c.product=='X'
then
     c.balance = c.balance + 20;
end

Basado en flujos: son sistemas que en base a diagramas de flujo aplican lógica de negocios a un token que pasa por dicho flujo, existen varios lenguajes visuales como el que implementan los sistemas BPM. La ventaja de estas definiciones es que son de alto nivel, son muy fácil de comprender, modificar, validar, etc.

Figura 5: BPMn

Drools es un BRMS muy poderoso, implementa tablas de decisiones, cuenta con su propio lenguaje de reglas llamado DRL y además permite integración con el motor de BPM de Jboss. La integración con nuestros sistemas es bastante simple.