¿Qué significa "lógica de negocios" en realidad si no es "todo código que no sea de terceros"?

He escuchado a la gente hablar mucho sobre lógica de negocios en el trabajo y en línea, y he leído varias preguntas en este sitio al respecto, pero el término aún no tiene mucho sentido para mí. Por ejemplo, aquí hay algunas declaraciones (parafraseadas) que a menudo veo:

• "La lógica empresarial es la parte de su programa que codifica las reglas comerciales reales". La mayoría de las definiciones que he leído son circulares como esta.

• "La lógica de negocios es todo único para su aplicación particular". No veo cómo esto es diferente de "su aplicación particular no es más que lógica de negocios", a menos que accidentalmente reinventamos un montón de ruedas para las que podríamos haber utilizado software de terceros. De ahí el título de la pregunta.

• "Debe haber una capa de lógica de negocios encima de su capa de acceso a datos y debajo de su capa de GUI". En el código que escribo, los accesos a la base de datos deben saber a qué datos se supone que deben acceder, y el código de la interfaz de usuario tiene que saber mucho sobre lo que se muestra para mostrarlo correctamente, y no hay nada que hacer realmente en el medio esos dos lugares además de pasar blobs de datos entre el cliente y el servidor. Entonces, ¿qué se supone que debe entrar en una capa de lógica de negocios?

• "La lógica de negocios debe estar separada de la lógica de presentación". La mayoría de las solicitudes de funciones que recibimos son para cambiar la lógica de presentación por razones comerciales. Si una de las reglas comerciales es mostrar los precios de los bonos del gobierno de los EE. UU. En notación 32 por defecto (al tiempo que proporciona una IU para que el usuario configure eso), la lógica de presentación necesita al menos saber que esta regla existe, si no implementarla completamente. Además, parece que una parte importante del diseño de UX es ayudar al usuario a comprender las reglas comerciales que nuestro software está tratando de implementar.

¿Es posible que realmente esté en un equipo que solo hace lógica de negocios, y toda la lógica no comercial está siendo realizada por otros equipos? ¿O todo el concepto de "lógica de negocios" como una entidad separada solo es viable para ciertas aplicaciones o arquitecturas?

Para ayudar a concretar las respuestas: imagina que tienes que volver a implementar la aplicación Domino's Pizza. ¿Cuál es la lógica comercial y cuál es la lógica no comercial de esa aplicación? ¿Y cómo sería posible poner esa lógica comercial de pedidos de pizza en su propia "capa" de código, sin que la mayor parte de la información de la pizza se filtre en las capas de acceso a datos y presentación?

Actualización: Llegué a la conclusión de que mi equipo probablemente está haciendo un 90% de código de interfaz de usuario y la mayoría, pero no todo, de lo que llamarías lógica empresarial proviene de otros equipos o empresas. Básicamente, nuestra aplicación es para monitoreardatos financieros, y casi todas las características son formas para que el usuario personalice qué datos ven y cómo los ven. No se realiza ninguna compra o venta (aunque integramos un poco con otras aplicaciones de nuestra empresa que lo hacen), y los datos reales son suministrados por muchas fuentes externas. Pero sí permitimos que los usuarios hagan cosas como enviar copias de sus "monitores" a otros usuarios, por lo que los detalles de cómo los manejamos probablemente califiquen como lógica comercial. En realidad, hay una aplicación móvil que actualmente habla con algunos de nuestros códigos de back-end, y sé exactamente qué parte de nuestro código de interfaz me gustaría que compartiera con nuestra interfaz de usuario en un mundo ideal (básicamente la M en nuestro cuasi-MVC) Supongo que ese es el BLL para nosotros.

Estoy aceptando la respuesta del usuario 61852 ya que me dio una comprensión mucho más concreta de lo que hace y no hace referencia la "lógica de negocios".

Te daré algunos consejos sobre las aplicaciones CRUD , ya que no tengo mucha experiencia en juegos o aplicaciones gráficamente intensivas:

• La lógica de negocios usualmente involucra reglas que el dueño del negocio aprendió o decidió durante años de operación, como por ejemplo: "rechazar cualquier crédito nuevo si el cliente aún no ha terminado de pagar el último" o "no vendemos el desayuno después de las 11 am " , o " lunes y martes, los clientes pueden comprar dos pizzas por el precio de una " .
• Por supuesto, la capa de presentación debe mostrar un mensaje que indique la disponibilidad de un descuento, o la razón del rechazo de un crédito, pero dicha capa no decide esas cosas, solo le está comunicando al usuario algo que sucedió bajo el capó.
• La lógica empresarial generalmente implica un flujo de trabajo , por ejemplo: "este ítem debe ser aprobado dentro de 3 días hábiles por algún gerente o puesto en una etapa de 'solicitud de información', si el cliente no ha presentado los documentos requeridos, entonces el ítem es rechazado" .
• La capa de presentación generalmente no se ocupa de ese tipo de flujo de trabajo, solo refleja los estados del flujo de trabajo.
• Además, la capa de acceso a datos suele ser sencilla, porque la lógica empresarial ya ha tomado decisiones. Esta capa se ve afectada cuando decide migrar sus datos de MS SQL Server a Oracle, por ejemplo
• Es cierto que a veces la GUI valida para evitar llamadas al servidor, pero eso es algo que debe hacerse con prudencia o podría tener mucha lógica de negocios en esa capa.
• Gran parte de su confusión puede haber surgido del hecho de que en su aplicación no hay separación de preocupaciones y efectivamente tiene demasiada lógica de negocios en la capa de presentación. El hecho de que (erróneamente) tenga lógica empresarial en su capa de aplicación o capa de acceso a datos no cambia el hecho de que sea lógica empresarial.
• Cosas como mostrar distancias en el sistema métrico en lugar de millas / yardas / pies no es una lógica de presentación, es una lógica de negocios . La capa empresarial tiene que devolver datos en las unidades requeridas y decirle a la capa de presentación qué unidades está manejando para que muestre las etiquetas apropiadas, pero definitivamente es una preocupación de lógica empresarial.
• La lógica empresarial no debería verse afectada por el hecho de que está utilizando Oracle ahora en lugar de Postgres, o por el hecho de que la compañía cambió su logotipo u hoja de estilo.
• Las reglas de negocio existen ya sea que lo automatices o no escribiendo una aplicación. Se pueden aplicar incluso cuando la empresa utiliza una solución de baja tecnología como lápiz y papel.
• Si tiene una versión móvil de su aplicación de escritorio, o una versión web , cada una de esas versiones tiene una capa de presentación diferente , pero (con suerte) la misma capa de negocios.

Parece que la mayor parte de su trabajo puede estar en la capa de la interfaz de usuario. Cambiar el formato de visualización por razones comerciales no implica ninguna lógica comercial. El cambio es un cambio en la lógica de la vista.

Ser capaz de cambiar el formato implica cierta lógica empresarial que posiblemente implique la persistencia de la preferencia.

La persistencia del formato a una cookie también se podría implementar en la capa de vista.

Sin embargo, esto podría implementarse de manera MVC. (Algunos modelos implementan la vista como su propio MVC capaz de manejar preferencias).

• La preferencia del usuario podría ser almacenada por el modelo (base de datos / cookie).
• El controlador reaccionaría a las solicitudes de formato cambiando la preferencia del usuario en el modelo.
• La vista se ajustaría a las preferencias del usuario. La preferencia se puede solicitar al modelo o el controlador puede proporcionarla.

Hacer una suposición educada sobre su aplicación.

• Hay un modelo que contiene bonos disponibles y datos de precios para ellos.
• Hay una vista que permite al usuario ver varias cosas que puede hacer: buscar bonos, mostrar precios, comparar rendimientos, tomar pedidos y que muestra los resultados devueltos por el modelo comercial en respuesta a la solicitud.

• La lógica de negocios maneja cosas como:

  • Realizar una búsqueda y proporcionar la vista para mostrar.
  • Encontrar precios para un bono y proporcionar la vista para mostrar.
  • Comparar rendimientos y proporcionar datos para que la vista se muestre.
  • Procesando pedidos y almacenándolos en el modelo.

Si esto se hace correctamente, debería ser posible proporcionar múltiples componentes de vista sin cambiar el modelo o la lógica empresarial. Por ejemplo, si el diseño actual es un sitio web, un nuevo servidor de vista para una aplicación de iPhone o Android usaría el modelo y la lógica comercial existentes. Estos pueden introducir nuevas funciones comerciales para proporcionar notificaciones push cuando se completa un pedido, lo que puede requerir cambios en varias capas.

Este desglose permite la separación de las preocupaciones.

• La capa de datos representada por el modelo tiende a ser relativamente estable.
• La capa empresarial es donde se aplican las decisiones comerciales: ¿se cumplirá / puede cumplirse la solicitud? ¿Se han obtenido todos los datos requeridos? ¿Está autorizado el usuario? ¿Hay alguna señal de alerta en la transacción?
• La capa de vista tiende a ser menos estable y puede haber más de una. Aquí es donde reside la apariencia de la aplicación. Es posible volver a revestir completamente una aplicación, sin cambiar las otras capas.