Si la estrategia va a
dividir el sistema en reglas de negocio y plugins hay que definir qué son las
reglas de negocio.
Estrictamente hablando
las reglas de negocio son las reglas o procedimientos que hacen ganar o ahorrar
dinero al negocio independientemente de si están implementadas en un
ordenador.
Por ejemplo, el hecho de
que un banco cobre un interés por un préstamo es una regla de negocio que hace
ganar dinero al banco. Es irrelevante si ese interés se calcula a través de un
sistema o con un ábaco.
A este tipo de reglas se
les va a denominar «Regla de negocio crítica» debido a que son críticas para el
negocio y estás existen incluso si no hubiera un sistema automatizado.
Las reglas de negocio
críticas necesitan algunos datos para operar y a estos datos se les
denomina «Datos críticos de negocio». Estos datos existen aunque el sistema no
esté automatizado.
Tanto las reglas de
negocio críticas como los datos de negocio críticos están
inextricablemente unidos así que son un buen candidato para encapsularlos en un
objeto. A esto objeto se le va a denominar «Entidad».
Entidad
Una entidad es un objeto
que encapsula un pequeño conjunto de datos críticos y un conjunto de reglas de
negocio críticas que operan sobre estos. La interfaz de la entidad consiste en
las funciones que implementan las reglas críticas de negocio que operan sobre
los datos críticos.
Por ejemplo, la entidad
préstamo se puede representar como una clase «Loan» con los datos críticos y
tres métodos que representan la interfaz para operar con esos datos.
Cuando se crea este tipo
de clase se está agrupando todo el software que implementa un concepto que es
crítico para el negocio pero está separado de otros conceptos. Esta clase es
una unidad independiente y es representativa del negocio. Está limpia de otro
conceptos como la base de datos, interfaz de usuarios, frameworks, etc. Esta
debería ser representativa del negocio en cualquier sistema, independientemente
de cómo se representa el sistema, como se almacenen esos datos, etc. La entidad
es puro negocio y poco más.
Las entidades no tienen
porque ser un clase. Todo lo que se necesita es vincular las reglas de negocio
críticas y los datos de negocio críticos en un único módulo que esté separado.
Casos de uso
No todas las reglas de
negocio son tan puras como las entidades. Algunas de las reglas de negocio
hacen o salvan dinero definiendo o restringiendo la manera en la que un sistema
automático opera. Estas reglas no deberían estar en un manual de entorno dado
que estas sólo tienen sentido sólo como parte del sistema automatizado.
Un caso de uso es una
descripción de la manera en la que se usa un sistema automatizado. Este
especifica los datos de entrada para el usuario, los datos de salida y los
pasos para el tratamiento de los datos de entrada para producir los datos de
salida. Un caso de uso describe una regla de negocio específica de la
aplicación en lugar de las reglas críticas de negocio de las entidades.
La siguiente figura
muestra un ejemplo de caso de uso. Se puede apreciar como en la última línea se
menciona al «customer». Esto es una referencia a la entidad «Customer» la cual
contiene las reglas críticas de negocio que gobiernan la relación entre el
banco y sus clientes.
Los casos de uso
contienen las reglas que especifican cómo y cuando se invocan las reglas de
negocio críticas dentro de las entidades. También se puede apreciar como el
caso de uso no describe la interfaz de usuario ni ninguna otra cosa que no sea
los datos que vienen de la interfaz y los datos que volverán a la interfaz.
Desde el caso de uso es imposible determinar si la interfaz es una web, una
consola, un servicio …
Un caso de uso es un
objeto el cual puede tener una o más
funciones que implementan las reglas de negocio específicas de la aplicación.
Este tiene los datos de entrada, de salida y las referencias a las entidades
apropiadas con las cuales este interactúa.
Las entidades no tienen
conocimiento sobre los casos de uso que las utilizan. Esto es otro ejemplo del
principio de inversión de dependencias (DIP). Las conceptos de alto
nivel, como las entidades, no saben nada acerca de los conceptos de bajo
nivel. Por el contrario, los casos de uso de bajo nivel conocen las entidades
de alto nivel.
Los casos de uso son de
más bajo nivel dado que son específicos a una aplicación y, por lo tanto, están
más cerca de las entradas y salidas. Las entidades son generalizaciones que se
pueden usar en muchas y distintas aplicaciones así que están más lejos de las
entradas y salidas. Los casos de uso dependen de las entidades mientras que las
entidades no dependen de los casos de uso.
Modelos de petición y
respuesta
Los casos de uso esperan
unos datos de entrada y producen unos datos de salida. No obstante, los casos
de uso bien formados no deberían tener noción alguna de cómo se comunican los
datos al usuario o ningún otro componente. No debería haber código con el caso
de uso conociendo HTML o SQL.
Los casos de uso aceptan
peticiones simples de estructuras de datos y devuelve estructuras simples de
datos. Estas estructuras de datos no son dependientes de nada. No derivan de
interfaces estándar como pueden ser «HttpRequest» o «HttpResponse».
Esta falta de
dependencias es crítica. Si los modelos de petición y respuesta no son
independientes, entonces los casos de uso que dependen de estos estarán
vinculados indirectamente.
Se podría llegar a
pensar que estas estructuras de datos contienen referencias a objetos de tipo
Entidad. Esto podría tener sentido dado que los modelos de peticiones y
respuestas comparten muchos datos. No obstante hay que evitar esa tentación ya
que el propósito de los dos objetos es muy diferente. A medida que pase el
tiempo estos cambiarán por diversas razones por lo que si se unen de alguna
manera se violará el «open-close principle» (CCP) y el «Single Responsability
Principle» (SRP).
Conclusiones
Las reglas de negocio
son la razón por las que un sistema software existe. Estas se modelan en código
de manera que albergan el núcleo de la funcionalidad con el propósito de hacer
o salvar dinero.
Las reglas de negocio
deberían permanecer impolutas y no deberían preocuparse por aspectos como la
base de datos o la interfaz de usuario. Estas deberían ser el código más
independiente y más reusable de todo el sistema.
No hay comentarios:
Publicar un comentario