La capa de persistencia, el lastre de la calidad en desarrollo de software en los últimos años

Comienza un nuevo proyecto, se vislumbra una idea de negocio y una aplicación que puede facilitar la vida a mucha gente. Lo primero que hacen los desarrolladores: Pensar en el modelo relacional y en qué tipos de datos guardará la base de datos. Lo segundo: Escribir las consultas en SQL.

En la era dorada de IBM, los empleados de finanzas no conocían ningún lenguaje de programación para hacer consultas en bases de datos -obviamente-. Además, en aquel momento, los lenguajes de programación eran horribles y cuanto menos, fáciles de aprender. Por ello, se desarrolló SQL y fue de lo mejorcito que le pudo ocurrir a la industria del software y a la empresarial. En ese momento, los empleados sólo tenían que aprender SQL que no es complicado para obtener los datos que necesitaban.

En el siglo XXI tenemos lenguajes de prorgramación que son más fáciles de aprender de lo que resulta SQL y ORMs que permiten olvidarse (en gran parte) de la capa de persistencia. Mantener código en Java es más sencillo que mantener código SQL incrustado en código Java. El código escrito en el mismo lenguaje que la lógica de negocio mantiene la cohesión en el software.

La complejidad es muy alta cuando para unos mismos tipos abstractos de datos es necesario pensar desde 2 dominios con diferentes estructuras: El dominio del software que se está desarrollando y el dominio de los datos dentro de la base de datos. Al final, lo que se obtiene es un diseño del dominio del problema marcado por cómo se almacenará el estado de los objetos.

Crear una base de datos a mano preocupándose por el tipo de datos y por las relaciones entre las entidades es un engorro y las máquinas de hoy en día cuentan con las prestaciones necesarias como para que casi todas las aplicaciones puedan permitirse no aprovechar al máximo dichas prestaciones y no someter el dominio del problema a los requerimientos de la capa de persistencia.

Cuando aparecieron las PaaS, las IaaS y NoSQL mi percepción de la capa de persistencia cambió a la de una cómoda caja negra a la que se le pasa un objeto para que lo guarde y se le pide otro objeto para que lo cargue y mientras se enfocan todos los esfuerzos en el dominio del problema.

En algún momento tras el despliegue en producción y si ha habido suerte con la aplicación, puede que el ORM no arroje los datos de rendimiento que debiera para soportar la escalada de usuarios y habrá que sustituir la capa de persistencia por consultas SQL o por un servicio externo de persistencia como Firebase.

Por lo tanto, de cara a posibles problemas de escalabilidad, mi postura no es la de “Me ahorro el ORM porque al final caerá” si no la de “Dejaré el software preparado para que la sustitución del ORM no sea frustrante” como plan de riesgos para cuando el sistema escale. Porque no somos magos para predecir el futuro y dónde fallará la aplicación ni ricos para permitirnos desarrollar lo que no aportará valor a corto plazo.

Anuncios

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 )

Google+ photo

Estás comentando usando tu cuenta de Google+. 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 )

Conectando a %s