Inicio > Metodología > ¿Dónde está ubicada la lógica de negocio de tu aplicación? (2) – Caso práctico de desacoplamiento

¿Dónde está ubicada la lógica de negocio de tu aplicación? (2) – Caso práctico de desacoplamiento

En uno de nuestros clientes se me planteó como objetivo de un proyecto independizar la capa de negocio de la capa de presentación, desacoplándola totalmente para que pudiera ser reutilizada desde cualquier entorno gráfico y dispositivo móvil, en una posible evolución a orientación a servicios (SOA).

Lo primero que revisé fue la estructura interna de la aplicación para determinar qué cambios se debían realizar para dejarla lo más reutilizable posible. Después tocó evaluar en tiempo, coste y recursos esos cambios, tratándolos como si fuesen un proyecto más. Aquí pensé en los responsables y en cómo iban a enfocarlos de cara a obtener la aprobación desde arriba ya que este tipo de proyectos son difíciles de justificar delante de los gestores, pues consumen recursos, cuestan dinero y no aportan ninguna nueva funcionalidad. Pero este coste se debe conocer pues con él pueden decidir si la opción de adaptar para el cambio resulta más barata o más cara que empezar todo de nuevo, en cuyo caso también se debe valorar lo que representa la pérdida de toda la inversión y trabajo efectuado hasta el momento.

Las características técnicas del Cliente, para que os pongáis en situación, eran:

–          Aplicación corporativa desarrollada en Oracle Forms&Reports y ejecutada sobre Oracle Application Server 10gR2.

–          SGBD Oracle 10gR2.

–          Entorno distribuido. Arquitectura 3-capas. Programación procedimental.

–          Lógica de negocio situada principalmente en el propio SGBD Oracle 10gR2.

–          Metodología de desarrollo tradicional.

Una de las primeras cuestiones que me planteé después de esa primera revisión fue:

¿Es correcto tener la lógica de negocio en el propio SGBD?

Y la respuesta es: depende. En general depende de si se trabaja con un lenguaje/entorno procedimental o con uno orientado a objetos. En un entorno orientado a objetos normalmente disponemos de más herramientas y más efectivas para la reutilización del código (herencia, encapsulamiento, abstracción, etc.), por lo que es más conveniente utilizar este potencial que normalmente nos facilitan los propios frameworks y su diseño, siempre que no se hayan implementado de forma procedimental pues entonces perderíamos ventajas en este sentido.

En este proyecto me encontré con un entorno de programación procedimental, por lo que situar las reglas de negocio en el servidor de datos es por lo menos recomendable por motivos como:

–       Rapidez en la ejecución.

–       Ejecución centralizada.

–       Ejecución transaccional.

–       Gestión de la concurrencia.

–       Fácil mantenimiento.

Los inconvenientes podrían venir más por el tipo de aplicación con el que estemos tratando. Así, en general es más recomendable el uso de reglas de negocio en el SGBD cuando la aplicación sea corporativa o cuando su administración pueda centralizarse. No es tan recomendable en aplicaciones comerciales por ciertos motivos como la seguridad, ocultación del código fuente, el despliegue de la aplicación en los clientes, etc. Aquí me encontraba ante una aplicación corporativa por lo que la eficiencia en la ejecución, la facilidad en el mantenimiento y la encapsulación respecto al resto de la aplicación convertían al  SGBD en una buena opción a la hora de situar las reglas de negocio.

Hasta aquí todo correcto. Pero detecté lo que venía a ser un problema, existía lógica de negocio fuera del propio SGBD, dentro de la capa de presentación. Esto ya es algo que he visto en otros clientes, con otras tecnologías y es, como he leído también, muy frecuente en entornos gráficos y web. Tiene hasta un nombre, botón mágico (magic pushbutton)  y es un reconocido antipatrón de diseño.

Esto me llevó a seguir el camino de los patrones-antipatrones de diseño y desarrollo, como buenas y malas prácticas documentadas. Y por encima de todo a documentarme en su aplicación y corrección con técnicas denominadas de refactorización, que dejan las cosas en su sitio, bien estructuradas y sencillas, todo ello sin afectar al comportamiento externo.

A más alto nivel me encontré con nuevas metodologías y estilos de desarrollo que ponen más énfasis en la adaptabilidad que en la previsibilidad, y que teorizan que la adaptación a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos. Son las nuevas metodologías y procesos ágiles de desarrollo de software. Entonces pienso que en la universidad sólo me hablaron de métodos de desarrollo tradicionales y como mucho con un cierto nivel de feedback. Cómo han cambiado las cosas y cómo nos adaptamos a ellas y las ponemos en práctica es la cuestión.

Siguiendo esta línea seguí algunos consejos (ref. Martin Fowler) que se deben tener muy en cuenta para tener éxito en un proyecto como éste:

–       No refactorizar y añadir funcionalidad al mismo tiempo.

–       Refactorizar en pasos cortos y deliberados. Refactorizar a menudo implica hacer muchos cambios que resulta un cambio a gran escala. Si se realizan pequeños cambios y se prueba después de cada paso, se evita una depuración prolongada.

–       Guardar la versión actual que funciona. Utilizar un sistema de control de versiones. Realizar la refactorización de forma que tenga la mínima repercusión en el sistema. Si la refactorización da errores, descartarla y volver al estado inicial sin ninguna duda. Aprender de los errores.

–       Tener un  buen juego de  pruebas antes de comenzar la refactorización. Probar con la mayor frecuencia posible para saber rápidamente si los cambios han afectado o no al comportamiento o funcionalidad externa.

Y también:

–       Tener muy claro el objetivo del proyecto. Descartar acciones (de refactorización) que no ayuden a conseguirlo de forma clara. Seguramente detectaremos otros antipatrones o malas prácticas en nuestro análisis pero como el tiempo y los recursos dedicados son limitados, como en todos los proyectos en general, lo mejor es dejarlos para futuras adaptaciones si convienen.  En definitiva, el objetivo no es arreglarlo todo, el objetivo es el que nos marque el cliente y por lo tanto adaptaremos sólo lo que esté en relación a ello.

–       Optimizar no es refactorizar. Mientras la optimización suele agregar complejidad, la refactorización simpleza. Normalmente si el objetivo es optimizar, uno debe primero refactorizar de modo que el código llegue a ser fácil de entender y por lo tanto fácil de optimizar.

Os dejo un ejemplo de algunas de las técnicas aplicadas:

Extraer método (Extract method).

Extraer método es una operación de refactorización que proporciona una manera sencilla de crear un nuevo método a partir de un fragmento de código de un miembro existente. El nuevo método que se ha extraído contiene el código seleccionado y el código seleccionado del miembro existente se reemplaza por una llamada al nuevo método. Convertir un fragmento de código en su propio método permite reorganizar el código de forma rápida y precisa para que sea posible volver a utilizarlo y lograr una mejor legibilidad.

Pasos seguidos de una forma genérica:

  1. Crear un nuevo paquete en la capa de negocio y darle un identificador adecuado que explique su propósito (ej. de técnica Renombrar método (rename method)). Por ejemplo: GESTION_CLIENTES en vez de GE_000001.
  2. Traspasar las Procesos de negocio de la capa de presentación al nuevo paquete como procedimientos o funciones.
  3. Buscar en el código extraído referencias a variables locales del entorno original (estas variables se convertirán en los parámetros, variables locales y resultado de los nuevos procedimientos y funciones).
  4. Crear los mínimos parámetros necesarios para evitar Long parameter list (lista de parámetros extensa), que incrementa el acoplamiento y lo hace más difícil de entender y mantener.
  5. Si una variable se usa sólo en el fragmento de código extraído, se declara en el nuevo procedimiento o función como variable local a éste.
  6. Si el valor de una variable sólo se lee en el fragmento de código extraído, la variable será un parámetro del nuevo procedimiento o función.
  7. Si una variable se modifica en el fragmento de código extraído, se intenta convertir el nuevo procedimiento en una función que da como resultado el valor que hay que asignarle a la variable modificada.
  8. Compilar el código para comprobar que todas las referencias a variables son válidas.
  9. Reemplazar el fragmento de código en el entorno original por una llamada al nuevo paquete y procedimiento o función.
  10. Eliminar las declaraciones del entorno original correspondientes a las variables que ahora son variables locales del nuevo procedimiento o función.
  11. Compilar y probar.

Finalmente, si queréis profundizar más en la teoría que hay detrás de todo esto tenéis una recopilación en: ¿Dónde está ubicada la lógica de negocio de tu aplicación? (1) – Teoría.

  1. Aún no hay comentarios.
  1. No trackbacks yet.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: