business-logic-layer - que - tier model
¿Qué consiste exactamente en ''Business Logic'' en una aplicación? (8)
Creo que confunde la lógica empresarial con los requisitos de su aplicación. No es lo mismo. Cuando alguien explica la lógica de su negocio, es algo así como:
"Cuando un usuario compra un artículo, tiene que proporcionar información de entrega. La información se valida con las reglas xyz. Después de eso, recibirá una factura y obtendrá puntos, lo que da un x% en descuentos por las ofertas y" (perdón por el mal ejemplo )
Cuando implemente estas reglas de negocio, tendrá que pensar en requisitos secundarios, como la forma en que se presenta la información, cómo se almacenará de forma persistente, la comunicación con los servidores de aplicaciones, cómo el usuario recibirá la factura, etc. Todos estos requisitos no son parte de la lógica comercial y deben desacoplarse de ella. De esta forma, cuando cambien las reglas comerciales, adaptarás tu código con menos esfuerzo. Es un hecho.
Algunas veces, la presentación replica parte de la lógica comercial, principalmente al validar la entrada del usuario. Pero también tiene que estar presente en la capa de lógica de negocios. En otras situaciones, es necesario mover alguna lógica comercial a la Base de datos, por problemas de rendimiento. Esto es discutido por Martin Fowler aquí .
He oído innumerables veces que "no debemos mezclar la lógica comercial con otro código" o declaraciones como esa. Creo que cada código que escribo (me refiero a los pasos del proceso) consiste en una lógica que está relacionada con los requisitos del negocio.
¿Alguien puede decirme qué consiste exactamente en lógica comercial? ¿Cómo se puede distinguir de otro código? ¿Hay alguna prueba simple para determinar qué es lógica de negocios y qué no?
La lógica empresarial es pura abstracción, existe independientemente de la materialización / visualización de los datos frente a su usuario, y es independiente 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 de negocios sería el cálculo del impuesto adeudado. No serían responsables de mostrar informes o guardar y recuperar una declaración de impuestos.
@Lars, "servicios" implica una cierta arquitectura.
No me gustan los nombres BLL + DAL de las capas, son más confusas que clarificadoras.
Llámalo DataServices y DataPersistence. Esto lo hará más fácil.
Servicios de manipulación, CRUDs de nivel de persistencia (Crear, Leer, Actualizar, Eliminar)
Para mí, la " lógica de negocios " compone todas las entidades que representan los datos aplicables al dominio del problema, así como la lógica que decide "qué hacer con los datos".
Entonces realmente debería consistir en "transporte de datos" (no acceso) y "manipulación de datos". En realidad, el acceso a datos (cosas que golpean al DB) debe estar en una capa diferente, al igual que el código de presentación.
Para simplificar las cosas en una sola línea ...
Business Logic sería un código que no depende de / no cambiará con un detalle de UI / implementación específico. Es una representación de código de las reglas, procesos, etc. que se definen por / reflejan el negocio que se está modelando.
Probablemente sea más fácil comenzar diciendo lo que 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 de negocios. Las comunicaciones de red no son lógica de negocios.
Para mí, la lógica de negocios son las reglas que describen cómo opera una empresa, no cómo opera una arquitectura de software. La lógica empresarial también tiene una tendencia a cambiar. Por ejemplo, puede ser un requisito comercial que cada cliente tenga una sola tarjeta de crédito asociada a su cuenta. Este requisito puede cambiar para que los clientes puedan tener varias tarjetas de crédito. En teoría, esto debería ser solo un cambio en la lógica comercial y otras partes de su software no se verán afectadas.
Entonces esa es la teoría. En el mundo real (como has descubierto), la lógica empresarial tiende a extenderse por todo el software. En el ejemplo anterior, es probable que deba agregar otra tabla a su base de datos para contener los datos adicionales de la tarjeta de crédito. Ciertamente deberá cambiar la UI.
Los puristas dicen que la lógica comercial siempre debe estar completamente separada, por lo que incluso estaría en contra de tener tablas llamadas "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 de su negocio en conjunto en lugar de mancharla en todo el sistema, pero (como con la mayoría de las teorías) debe ser pragmático en el mundo real.
Si contiene algo sobre cosas como formulario, botón, etc. no es una lógica comercial, es la capa de presentación. Si contiene persistencia para archivo o base de datos, es DAL. Cualquier cosa en el medio es lógica de negocios. En realidad, cualquier cosa que no sea UI a veces recibe el nombre de "lógica de negocios", pero debería ser algo que se relaciona con el dominio del problema, no con el mantenimiento de la casa.
Simplemente defina lo que está haciendo en inglés simple. Cuando estás diciendo cosas de negocios, como "haz que los demás sufran", "roba ese dinero", "destruye esta parte de la tierra", estás hablando de la capa de negocios. Para que quede claro, las cosas que te excitan van aquí.
Cuando dices "mostrar esto aquí", "no mostrar eso", "hacerlo más hermoso", estás hablando de la capa de presentación. Estas son las cosas que emocionan a sus diseñadores.
Cuando dices 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 le dicen qué conservar para siempre a toda costa.