Capa de Negocio (Parte 2): Domain Model

Continuando con los patrones de la capa de negocio llega el turno de Domain Model

Patrón Domain Model 

Al contrario que el patrón Transaction Script, la idea ahora es poder soportar lógica de negocio muy compleja por medio de Clases (si ahora solo puede ser POO).

El patrón Domain Model, nos dice que ahora habrá que modelar el negocio y bajarlo a nivel de entidades, que en algún momento se traducirán a clases.

En muchas ocasiones se confunde el Modelo de Dominio con el Modelo Entidad - Relación (Diagrama de la base de datos), cuando lo cierto es que estos dos modelos son muy diferentes, ya que el modelo de dominio no solo maneja datos, si no también procesos y algunos expertos dicen que tampoco debe permitir herencia.

Por ejemplo: Imaginemos que queremos modelar el proceso de apertura de una cuenta bancaria. Para abrir una cuenta bancaria se necesita un cliente, una operación de apertura(un deposito) y crear obviamente una nueva cuenta.

Seguramente un E-R para este tipo de procesos será mas complejo, pero para fines explicativos, creo que será suficiente.

Ahora vamos a ver como se vería un Modelo de Dominio

Ah!!, ya no son tan iguales cierto, y es que el modelo de dominio tiende a encapsular de alguna manera comportamiento, que puede afectar a mas de una tabla, como es el caso de la entidad "CuentaBancaria".

Tan solo el método crearCuenta de alguna manera invoca peticiones hacia las tablas CUENTA_BANCARIA, TIPO_CUENTA, OPERACION_BANCARIA y TIPO_OPERACION

Y porque no crear una clase llamada "OperacionBancaria", la respuesta es muy simple, no se me ocurre algún método particular para esta clase, es decir, operacionBancaria es una buena tabla para poder almacenar todas las transacciones que hacemos con la cuenta, cargos o abonos y al final podemos sacar un buen estado de cuenta de esta tabla, pero no tiene comportamiento propio, y es que el problema de tener Clases que no tengan comportamiento propio nos hace caer en un Antipatrón llamado "Anemic Domain Model"

¿Qué es el Antipatrón " Anemic Domain Model" (Modelo de Dominio Flaco)? 

Como su nombre indica un Antipatrón es algo como el Némesis de un patrón, un enemigo natural, pero como todo enemigo natural siempre hay algo que comparten, algo que los hace acérrimos rivales puede ser la fuerza, velocidad o algo. En este caso en particular es que ambos son Clases.

Incurrimos en este antipatrón cuando tenemos Clases sin comportamiento y que solo tienen Atributos o viceversa. Dado que los objetos de alguna manera tratan de modelar nuestra realidad no hay objetos que no tengan una funcionalidad especifica, o que no tengan características, no podría imaginar algún objeto que no sirva para nada o que no tenga ninguna característica.

Por esta razón se les denominan anémicos, porque les hace falta comer algo para estar en forma, le hace falta tener o bien métodos o bien atributos.

¿Como se cuales son las entidades de negocio?

La verdad no es tan complicado, solo hay que responder algunas preguntas:

• ¿Qué es? 
• ¿Para qué sirve? 
• ¿Cómo funciona? 
• ¿Qué características tiene? 

Si aplicamos esto al ejemplo anterior, podemos observar los siguiente:

Entidad: Cuenta Bancaria.  ¿Que es? Es un concepto de banco que esta asociado a un Cliente, una Cuenta Bancaria es el eje principal para hacer operaciones y es la relación entre el Banco y el Cliente.  ¿Para que sirve? Es una especie de caja fuerte, en la cual un cliente puede guardar dinero electrónico, y disponer de el mediante algún mecanismo igualmente electrónico.  ¿Como funciona? Inicialmente debe ser creada con un deposito (agregar dinero a la caja), puede incrementar el saldo por medio depósitos en ventanilla o alguna transferencia electrónica a favor de la cuenta a lo cual se le denomina "abono" a la cuenta, para disponer del contenido se puede hacer mediante un pago electrónico o disposición de efectivo, a lo cual se le denomina "Cargo".  ¿Que características tiene? Cada cuenta es de un tipo especifico (Nómina, Ahorro, etc.), esta ligada a un solo Cliente pero un cliente puede tener muchas, tiene una fecha de apertura siempre debe contar con una cantidad de dinero disponible y los movimientos bancarios que ha tenido.

Cuando la entidad que se desea validar responde todas las preguntas fácilmente, es muy claro que es una verdadera entidad. Ahora vamos a intentar validar el concepto Operación Bancaria.

Entidad: Operación Bancaria ¿Que es? Es una transacción que involucra una cuenta y un movimiento ya sea de cargo o abono hacia la misma. ¿Para que sirve? Para marcar un movimiento de una Cuenta Bancaria.  ¿Como funciona? Cuando una Cuenta Bancaria hace un movimiento de entra o salida de dinero esto genera una operación bancaria, la cual es de un tipo(Cargo o Abono).  ¿Que características tiene? Fecha de la operación, Tipo de movimiento e Importe.

 "Oye, pero si contestó todas las preguntas", es cierto pero analicemos las respuestas:

Es muy claro que tiene características y muy importantes por cierto, pero el funcionamiento, esta 100% ligado a un resultado de otra entidad "Cuenta Bancaria", lo que quiere decir que no tiene comportamiento propio y en todas sus respuestas siempre menciona "Cuenta Bancaria", lo que quiere decir que es una parte o consecuencia de una Cuenta Bancaria.

No digo que se tenga que hacer esto a todas las entidades de negocio, pero es una buena forma de salir de dudas, sobre todo con aquellas entidades de las que no estamos tan seguros.

Pros y contras 

Ahora vamos a lo interesante

 Pros:

• Nos permite modelar de una forma mas adecuada como funciona un negocio. 
• Aplicar cambios en el negocio es muy sencillo. 
• No hay replicación de código.
• Las refactorizaciones se resumen a una clase especifica y no a todo el sistema. 
• Si el negocio crece, es mas sencillo modelarlo y cambiar el código. 
• Las pruebas se reducen a probar el funcionamiento de cada clase y como se comporta. 

 Contras: 

• Los errores no detectados en el modelo de dominio pueden repercutir seriamente en un futuro. 
• El proceso de desarrollo depende de la especificación del modelo, por lo tanto tiende a ser mas lento. 
• Para validar el modelo, en ocasiones hacen falta varias revisiones, lo cual también toma cierto tiempo. 

Conclusión

 Si tienes un negocio muy complejo y/o cambiante y el tiempo no es un asunto de mucha relevancia (en el mundo del desarrollo eso es una epifanía), esta es una muy buena alternativa para solucionar el problema.


En el siguiente y ultimo articulo correspondiente a la Capa de Negocio veremos que es el Table Module y pueden revisar el patron anterior Transaction Script