Articulo de referencia

lógica empresarial

En el software , la lógica de negocio o lógica de dominio es la parte del programa que codifica las reglas de negocio del mundo real que determinan cómo se pueden crear, almacen...

En el software , la lógica de negocio o lógica de dominio es la parte del programa que codifica las reglas de negocio del mundo real que determinan cómo se pueden crear, almacenar y modificar los datos . Se diferencia del resto del software, que puede ocuparse de detalles de bajo nivel como la gestión de una base de datos , la visualización de la interfaz de usuario , la infraestructura del sistema o, en general, la conexión de las distintas partes del programa.

Detalles y ejemplo

Lógica empresarial:

  • Prescribe cómo interactúan entre sí los objetos de negocio.
  • Aplica las rutas y los métodos mediante los cuales se accede y se actualizan los objetos de negocio.

Reglas de negocio:

  • Modela objetos empresariales reales (como cuentas, préstamos, itinerarios e inventarios).

La lógica de negocio comprende: [ 1 ]

  • Los flujos de trabajo son tareas ordenadas que consisten en pasar documentos o datos de un participante (una persona o un sistema informático) a otro.

La lógica empresarial debe distinguirse de las reglas empresariales. [ 2 ] La lógica empresarial es la parte de un sistema empresarial que determina cómo se transforman o calculan los datos y cómo se dirigen a las personas o al software (flujo de trabajo). Las reglas empresariales son expresiones formales de la política empresarial. Todo lo que es un proceso o procedimiento es lógica empresarial, y todo lo que no es ni un proceso ni un procedimiento es una regla empresarial. Dar la bienvenida a un nuevo visitante es un proceso (flujo de trabajo) que consta de pasos a seguir, mientras que decir que todo nuevo visitante debe ser bienvenido es una regla empresarial. Además, la lógica empresarial es procedimental, mientras que las reglas empresariales son declarativas. [ 3 ]

Por ejemplo, un sitio web de comercio electrónico podría permitir a los visitantes agregar artículos a un carrito de compras, especificar una dirección de envío y proporcionar información de pago. La lógica de negocio del sitio web podría incluir un flujo de trabajo como el siguiente:

  • La secuencia de eventos que ocurren durante el proceso de pago, por ejemplo, un formulario de varias páginas que primero solicita la dirección de envío, luego la dirección de facturación, la siguiente página contendrá el método de pago y la última página mostrará felicitaciones.

También habrá reglas de uso del sitio web:

  • Si se añade un artículo más de una vez desde la página de descripción del artículo, se incrementará la cantidad disponible para dicho artículo.
  • Formatos específicos que deben seguir la dirección postal, la dirección de correo electrónico y la información de la tarjeta de crédito del visitante.
  • Un protocolo de comunicación específico para comunicarse con la red de tarjetas de crédito.

El software del sitio web también contiene otro código que no se considera parte de la lógica de negocio ni de las reglas de negocio:

  • Contenido periférico no relacionado con los datos comerciales principales, como el HTML que define los colores, la apariencia, la imagen de fondo y la estructura de navegación del sitio.
  • Código genérico para el manejo de errores (por ejemplo, que muestra la página de error HTTP 500).
  • Código de inicialización que se ejecuta cuando el servidor web inicia el sitio y que configura el sistema.
  • Supervisar la infraestructura para asegurar que todas las partes del sitio funcionen correctamente (por ejemplo, que el sistema de facturación esté disponible).
  • Código genérico para establecer conexiones de red, transmitir objetos a la base de datos , analizar la entrada del usuario mediante eventos HTTP POST, etc.

Lógica de negocio y niveles/capas

En teoría, la lógica de negocio ocupa el nivel intermedio de una arquitectura de tres niveles.

La lógica de negocio puede ubicarse en cualquier parte de un programa. Por ejemplo, dado un formato específico para una dirección, se podría crear una tabla de base de datos con columnas que correspondan exactamente a los campos especificados en la lógica de negocio, y agregar comprobaciones de tipo para garantizar que no se ingresen datos no válidos.

La lógica de negocio suele cambiar. Por ejemplo, el conjunto de formatos de dirección permitidos podría cambiar cuando un minorista en línea comienza a enviar productos a un nuevo país. Por lo tanto, a menudo se considera deseable que el código que implementa la lógica de negocio esté relativamente aislado o débilmente acoplado . Esto aumenta la probabilidad de que los cambios en la lógica de negocio requieran un pequeño conjunto de cambios de código, en una sola parte del código. El código distante pero fuertemente acoplado también crea un mayor riesgo de que el programador solo realice algunos de los cambios necesarios y omita parte del sistema, lo que puede provocar un funcionamiento incorrecto. [ 4 ]

Una arquitectura de múltiples niveles formaliza este desacoplamiento mediante la creación de una capa de lógica de negocio independiente de otras capas, como la capa de acceso a datos o la capa de servicios . Cada capa solo conoce una cantidad mínima de información sobre el código de las demás capas, la suficiente para realizar las tareas necesarias. Por ejemplo, en un paradigma modelo-vista-controlador , las capas de controlador y vista se pueden reducir al mínimo, concentrando toda la lógica de negocio en el modelo. En el ejemplo del comercio electrónico, el controlador determina la secuencia de páginas web en el proceso de compra y también se encarga de validar que el correo electrónico, la dirección y la información de pago cumplan con las reglas de negocio (en lugar de dejar esta tarea a la base de datos o al código de acceso a la base de datos de nivel inferior).

Existen paradigmas alternativos. Por ejemplo, con entidades comerciales relativamente simples, una vista y un controlador genéricos podrían acceder a objetos de la base de datos que contienen toda la lógica comercial relevante sobre los formatos que aceptan y los cambios que son posibles (conocido como modelo de base de datos ).

Algunos esquemas por niveles utilizan una capa de aplicación distinta o una capa de servicio , o consideran que la capa de lógica de negocio es la misma que una de ellas.

Herramientas y técnicas

La lógica de negocio se puede extraer del código procedimental utilizando un sistema de gestión de reglas de negocio (BRMS). [ 5 ]

El enfoque de reglas de negocio en el desarrollo de software utiliza sistemas de gestión de reglas de negocio (BRMS) y garantiza una separación estricta entre la lógica de negocio y el resto del código. Los sistemas de gestión de la interfaz de usuario son otra tecnología empleada para lograr esta separación. El botón mágico se considera un "antipatrón": una técnica que, en este caso, crea restricciones indeseables que dificultan la codificación de la lógica de negocio de forma que sea fácil de mantener.

Un modelo de dominio es una representación abstracta de los tipos de almacenamiento de datos que requieren las reglas de negocio.

Véase también

Referencias

  1. Steven Minsky (27 de marzo de 2005). "El desafío de la adopción de BPM" . Techtarget . eBizQ.
  2. "Definición de lógica de negocio" . 24/12/2013.
  3. William Ulrich. "Simposio sobre reglas de negocio de OMG" (PDF) . Archivado del original (PDF) el 24 de diciembre de 2013.
  4. Khawar Zaman Ahmed y Cary E. Umrysh (17 de octubre de 2001). «Introducción al software empresarial». Desarrollo de aplicaciones Java empresariales con J2EE y UML . Addison-Wesley. ISBN 0-201-73829-5.
  5. Owen, James (19 de septiembre de 2003). "Sacar a la luz la lógica empresarial" . Java empresarial. InfoWorld . Consultado el 21 de julio de 2020 .

Lecturas adicionales

  • Brett McLaughlin (marzo de 2002). «Lógica empresarial, parte 1» . Creación de aplicaciones empresariales Java, vol. I: Arquitectura . O'Reilly and Associates. ISBN 0-596-00123-1.— McLaughlin analiza el patrón de fachada para implementar la capa de negocio de una aplicación.
  • Kathy Bohrer (noviembre de 1997). "El middleware aísla la lógica de negocio" . Object Magazine . 7 (9). Nueva York, EE. UU.: SIGS Publications, Inc.: 41–46 . ISSN 1055-3614 . 
  • Harumi Kuno; Mike Lemon; Alan Karp y Dorothea Beringer (2001). "Conversaciones + Interfaces = Lógica de negocio". En F. Casati; D. Georgakopoulos y M.-C. Shan (eds.). Tecnologías para servicios electrónicos: Segundo taller internacional, TES 2001, Roma, Italia, 14-15 de septiembre de 2001, Actas . Lecture Notes in Computer Science. Vol.  2193. Springer Berlin / Heidelberg. ISSN 0302-9743 . 
  • Volker Turau (2002). «Un marco para la generación automática de aplicaciones web de entrada de datos basadas en XML» . Actas del simposio ACM de 2002 sobre computación aplicada, Madrid, España: Aplicaciones web y de comercio electrónico . ACM Press. pp. 1121–1126 . ISBN  1-58113-445-2.— Turau presenta un marco de aplicación implementado mediante Java Servlets y JavaServer Pages que permite la separación entre la lógica de negocio y la lógica de presentación, lo que posibilita que el desarrollo de cada una se lleve a cabo en paralelo por vías relativamente independientes pero que cooperan entre sí.
  • Pau, L.-F. y Vervest, PHM (8 de diciembre de 2003). "Gestión de procesos de negocio basada en redes: integración de la lógica empresarial en redes de comunicaciones". Serie de informes ERIM sobre investigación en gestión. Universidad Erasmus . hdl : 1765/1070 .{{cite journal}}: Cite journal requires |journal=( help ) — Pau y Vervest desarrollan un enfoque para la incrustación de lógica de negocio en la red de comunicaciones que subyace a una aplicación distribuida con una multiplicidad de actores , con el fin de optimizar la asignación de recursos de negocio desde un punto de vista de red.
  • Directrices de la capa empresarial