Arquitectura de Aplicaciones Web - Capa de Negocio


Introducción

La capa de negocio contiene la lógica principal de procesamiento de datos dentro de nuestra aplicación Web. Se comunica con la capa de presentación para obtener las entradas del usuario y presentar la información resultante, así como la capa de acceso a datos o directamente con servicios para realizar sus operaciones.

Componentes de la capa de negocio

























  • Componentes de negocio. Encapsulan las reglas de negocio o la forma en que los datos adquiridos desde la capa de presentación deben ser manipulados o transformados acorde al problema que tenemos que resolver. Estos componentes pueden cambiar o evolucionar con los requerimientos de negocio.
  • Entidades de negocio. Se utilizan para pasar o intercambiar datos entre componentes de negocio. Ejemplos típicos pueden ser las facturas, productos, contratos o clientes. Internamente están formados por estructuras de datos o clases de lenguajes orientados a objetos serializables.
  • Flujo de trabajo. Muchos procesos de negocio son tratados como un conjunto de pasos dependientes unos de otros que deben ejecutarse coordinados y en un orden determinado. Un ejemplo clásico es la aprobación de un contrato que implica la aprobación de los términos y condiciones así como las firmas de los intervinientes. En muchas ocasiones estos flujos de trabajo son procesos de negocio de múltiples pasos que requieren intervención del usuario y por lo tanto pueden ser de larga duración.
  • Fachada de aplicación. Una fachada de aplicación combina múltiples operaciones de negocio dentro de un único mensaje. Existen varias formas de enviar este mensaje desde una capa de presentación para que las operaciones de negocio puedan ser tratadas. Este es un componente opcional que proporciona otra facilidad de proceso a nuestra capa de negocio

 Factores a considerar al desarrollar la capa de negocio
  
  • Crear un diseño general de la capa de negocio

    1. Identificar los consumidores de la capa de negocio
    2. Determinar como se va a exponer la capa de negocio
    3. Determinar los requerimientos de seguridad de la capa de negocio
    4. Determinar los requerimientos de validación de la capa de negocio
    5. Determinar los requerimientos de caché de la capa de negocio
    6. Determinar la estrategia de tratamiento de excepciones de la capa de negocio

  • Diseñar los componentes de negocio

    1. Identificar los componentes de negocio que la aplicación va a utilizar
    2. Determinar las interacciones, acoplamiento y ubicación de los componentes de negocio
    3. Seleccionar el soporte transaccional adecuado
    4. Identificar como se van a tratar las reglas de negocio
    5. Identificar los patrones que se ajusten a los requerimientos de negocio

  • Diseñar las entidades de negocio

    1. Identificar los formatos de datos comunes de las entidades de negocio
    2. Seleccionar el formato de datos adecuado
    3. Seleccionar el diseño correcto de la entidad de negocio
    4. Seleccionar el tipo de serialización que vamos a necesitar

  • Diseñar los componentes de flujos de trabajo

    1. Identificar los escenarios de uso de flujos de trabajo
    2. Determinar cuantas reglas van a ser tratadas
    3. Determinar como van a ser tratadas las reglas
    4. Seleccionar una solución de flujo de trabajo para nuestra aplicación
    5. Crear componentes de negocio que soporten flujos de trabajo
  
Consideraciones de diseño de la capa de negocio

  • Decidir cuantas capas de negocio vamos a tener en nuestra aplicación Web. El uso de varias capas de negocio simplifica el mantenimiento de nuestra aplicación. Solo modificamos o evolucionamos la capa de negocio que sea necesario y no toda la capa de negocio lo cuál tendría un impacto mucho mayor
  • Identificar las responsabilidades de nuestra capa de negocio.  Debemos crear una capa de negocio para procesar reglas de negocio complejas, transformaciones de datos y realizar validaciones.
  • No mezclar diferentes tipos de componentes en la capa de negocio. Una de las misiones fundamentales de la capa de negocio es desacoplar la lógica de negocio de la capa de presentación y de la capa de acceso a datos
  •  Reutilizar lógica de negocio común. Otra de las misiones fundamentales de la capa de negocio es la de crear en un espacio común, lógica de negocio que pueda ser reutilizable, simplificando el mantenimiento y reduciendo el tamaño de nuestra aplicación Web
  • Identificar los consumidores de la capa de negocio. Esto nos va a ayudar a determinar como vamos a exponer nuestra capa de negocio (como otras capas de la aplicación van a interactuar con ella). Por ejemplo, si una aplicación externa va a interactuar con la capa de negocio, deberíamos exponerla como un servicio
  • Reducir el tráfico (idas y vueltas) cuando accedemos a una capa de negocios remota. Esto de consigue con el uso de una interfaz basada en mensajes y con la implementación de una fachada de aplicación en nuestra capa de negocio. De esta forma con un solo mensaje podrían realizarse varias operaciones, en vez de realizar múltiples llamadas a diferentes métodos u operaciones de un servicio
  • Evite al máximo el acoplamiento con la capa de presentación. Considere el uso interfaces basadas en mensajes, entre la capa de presentación y la de negocio. En la propia capa de negocio, utilice interfaces de objetos públicas, definiciones comunes de interfaces, clases abstractas o mensajes.
 Problemas comunes en el diseño de la capa de negocios

A continuación se enumeran un conjunto de problemas comunes que se presentan a la hora de diseñar la capa de negocio de una aplicación Web y que deben ser revisados por los arquitectos y los desarrolladores.

Categoría
Problemas comunes
Cache
  • Guardar en cache datos que no se van a reutilizar
  • Guardar datos sensibles sin encriptar
  • Selección incorrecta del almacenamiento para caché
  • Selección de un mecanismo de caché incorrecto cuando la aplicación está desplegada en una granja de servidores Web
  • Asumir que un dato está en caché cuando realmente no lo está
  • Almacenar grandes cantidades de datos en caché
Autenticación
  • Aplicar autenticación a la capa de negocios cuando no lo requiere
  • Diseñar un mecanismo de autenticación personalizado (siempre que podamos deberíamos basarnos en estándares)
  • No utilizar mecanismos de single sign-on cuando lo requiera
Autorización
  • Granularidad incorrecta para los roles (alguien hace más de lo que debe hacer o menos de lo que debe hacer)
  • Uso de delegación o impersonación (hacemos algo identificándonos como otro usuario) cuando no hace falta
  • Mezclar el código de autorización con la propia lógica de negocio
Componentes de negocio
  • Mezclar lógica de negocio con lógica de acceso a datos
  • No considerar el uso de interfaces basadas en mensaje para exponer componentes de negocio
Entidades de negocio
  • Uso de un dominio de negocio inapropiado para modelar una entidad
  • Selección de formatos de datos incorrectos
  • No considerar los requerimientos de serialización
Acoplamiento y cohesión
  • Fuerte acoplamiento entre capas
  • Falta de una separación clara de responsabilidades en la capa de negocio
  • Fallo al utilizar una interfaz basada en mensajes entre capas de la aplicación Web
Concurrencia y transacciones
  • No seleccionar el modelo correcto de concurrencia de datos
  • Permitir que transacciones de larga duración bloqueen los datos
Acceso a datos
  • Acceso a la base de datos directamente desde la capa de negocio
  • Mezclar lógica de acceso a datos con lógica de negocio dentro de componentes de negocio
Tratamiento de excepciones/errores
  • Mostrar al usuario datos sensibles como parte de mensajes de error
  • No hacer log detallados cuando se producen excepciones
Logging e Instrumentación
  • Fallo al no instrumentar correctamente los componentes de negocio
  • Fallo al no registrar en el log los problemas o errores de componentes críticos de sistema y de negocio
  • No eliminar fallos del sistema de log
Validación
  • Asumir que los datos están validados correctamente en la capa de presentación
  • Fallo en el tratamiento de errores de validación
  • No identificar las reglas de negocio apropiadas para las validaciones
  • No reutilizar la lógica de validación
  • No validar todos los aspectos de un parámetro tales como rango, tipo y formato
Interfaz del servicio
  • Dividir la interfaz de un servicio
  • Implementar reglas de negocio en la interfaz de un servicio
  • Fallo al no considerar lo estándares para intercambiar información que hacen al servicio interoperable
Flujos de trabajo
  • Selección incorrecta de patrones de flujo de trabajo
  • No considerar como tratar errores y excepciones en todos los estados del flujo
  • Seleccionar un tecnología incorrecta de flujo de trabajo

posted under |

3 comentarios:

Unknown dijo...

Genial articulo

israrp dijo...

Buen artículo, estaría bueno entrar en los detalles

UX Design Studio dijo...

This is the precise weblog for anybody who needs to seek out out about this topic. You notice so much its almost arduous to argue with you. You positively put a brand new spin on a subject that's been written about for years. Nice stuff, simply nice!

Publicar un comentario

Entrada más reciente Entrada antigua Inicio