¿En qué consiste exactamente la 'Lógica de Negocios' en una aplicación?

Question

He escuchado innumerables veces que "no deberíamos mezclar la lógica empresarial con otro código" o declaraciones como esa.Creo que cada código que escribo (me refiero a los pasos de procesamiento) consta de una lógica relacionada con los requisitos comerciales.

¿Alguien puede decirme en qué consiste exactamente la lógica empresarial?¿Cómo se puede distinguir de otro código?¿Existe alguna prueba sencilla para determinar qué es lógica empresarial y qué no?

Answer 1

Simplemente define lo que estás haciendo en un lenguaje sencillo.Cuando dices cosas desde el punto de vista empresarial, como "hacer sufrir a esos", "robar ese dinero", "destruir esta porción de tierra", estás hablando de una capa empresarial.Para que quede claro, las cosas que te entusiasman van aquí.

Cuando dices "muestra esto aquí", "no muestres aquello", "hazlo más hermoso", estás hablando de la capa de presentación.Estas son las cosas que entusiasman a sus diseñadores.

Cuando dice cosas como "guardar esto", "obtener esto de la base de datos", "actualizar", "eliminar", etc.estás hablando de la capa de datos.Estas son las cosas que te dicen qué conservar para siempre a toda costa.

Answer 2

Probablemente sea más fácil empezar diciendo qué no es lógica de negocios.El acceso a la base de datos o al disco no es una lógica empresarial.La interfaz de usuario no es lógica empresarial.Las comunicaciones en red no son lógica empresarial.

Para mí, la lógica empresarial son las reglas que describen cómo opera una empresa, no cómo opera una arquitectura de software.La lógica empresarial también tiende a cambiar.Por ejemplo, puede ser un requisito comercial que cada cliente tenga una única tarjeta de crédito asociada a su cuenta.Este requisito podrá cambiar para que los clientes puedan tener varias tarjetas de crédito.En teoría, esto debería ser sólo un cambio en la lógica empresarial y otras partes de su software no se verán afectadas.

Entonces esa es la teoría.En el mundo real (como habrá descubierto), la lógica empresarial tiende a extenderse por todo el software.En el ejemplo anterior, probablemente necesitará agregar otra tabla a su base de datos para contener los datos adicionales de la tarjeta de crédito.Seguramente necesitarás cambiar la interfaz de usuario.

Los puristas dicen que la lógica empresarial siempre debería estar completamente separada y por eso incluso estarían en contra de tener tablas denominadas "Clientes" o "Cuentas" en la base de datos.Llevado al extremo, terminaría con un sistema increíblemente genérico e imposible de mantener.

Definitivamente hay un fuerte argumento a favor de mantener la mayor parte de la lógica empresarial unida en lugar de mancharla por todo el sistema, pero (como ocurre con la mayoría de las teorías) es necesario ser pragmático en el mundo real.

Answer 3

Creo que confundes la lógica empresarial con los requisitos de tu aplicación.No es lo mismo.Cuando alguien explica la lógica de su negocio es algo como:

"Cuando un usuario compra un artículo tiene que proporcionar información de entrega.La información se valida con reglas x y z.Después de eso recibirá una factura y ganará puntos, eso le da x% en descuentos para las y ofertas" (perdón por el mal ejemplo)

Cuando implementes estas reglas de negocio tendrás que pensar en requisitos secundarios, como cómo se presenta la información, cómo se almacenará de forma persistente, la comunicación con los servidores de aplicaciones, cómo recibirá el usuario la factura, etc.Todos estos requisitos no forman parte de la lógica empresarial y deben desvincularse de ella.De esta forma, cuando las reglas de negocio cambien adaptarás tu código con menos esfuerzo.Es un hecho.

A veces, la presentación replica parte de la lógica empresarial, principalmente en la validación de la entrada del usuario.Pero también tiene que estar presente en la capa de lógica empresarial.En otras situaciones, es necesario mover alguna lógica de negocio a la base de datos, por cuestiones de rendimiento.Esto es discutido por Martin Fowler. aquí.

Answer 4

Para simplificar las cosas a una sola línea...
La lógica empresarial sería un código que no depende/no cambiará con una interfaz de usuario/detalles de implementación específicos.Es un código de representación de las reglas, procesos, etc.que están definidos por/reflejan el negocio que se está modelando.

Answer 5

No me gustan los nombres BLL+DAL de las capas, son más confusos que clarificadores.
Llámelo DataServices y DataPersistence.Esto lo hará más fácil.

Manipulación de servicios, CRUD de nivel de persistencia (Crear, Leer, Actualizar, Eliminar)

Answer 6

Para mí, " lógica de negocios "conforma todas las entidades que representan datos aplicables al dominio del problema, así como la lógica que decide "qué hacer con los datos".

Por lo tanto, realmente debería consistir en "transporte de datos" (no acceso) y "manipulación de datos".En realidad, el acceso a los datos (las cosas que llegan a la base de datos) debería estar en una capa diferente, al igual que el código de presentación.

Answer 7

Si contiene algo sobre cosas como formulario, botón, etc.No es una lógica de negocios, es una capa de presentación.Si contiene persistencia en un archivo o base de datos, es DAL.Cualquier cosa intermedia es lógica empresarial.En realidad, cualquier cosa que no sea UI a veces se denomina "lógica de negocios", pero debería ser algo que concierna al dominio del problema, no al mantenimiento.

Answer 8

La lógica empresarial es pura abstracción, existe independientemente de la materialización/visualización de los datos frente al usuario y de la persistencia de los datos subyacentes.

Por ejemplo, en el software de preparación de impuestos, una responsabilidad de las clases de lógica empresarial sería el cálculo del impuesto adeudado.No serían responsables de mostrar informes ni de guardar y recuperar una declaración de impuestos.

---

@Lars, "servicios" implica una determinada arquitectura.