En software, arquitectura es una estructura de diseño que se implementa para el desarrollo de una aplicación es difícil de cambiar, cuando se desarrolla se deben tomar decisiones las decisiones que afecten cómo se desarrolla de ahí para adelante el resto del sistema y que son muy complejas de aislar y cambiar en un futuro son decisiones arquitectónicas y se toma como un pilar en el diseño del sistema en general. Un ejemplo puede ser el decidir hacer una aplicación completa por capas, donde se escogen las capas a desarrollar, se da la responsabilidad de cada una de ellas y se empieza a desarrollar, esta determinación es difícil de cambiar una vez avanzada la etapa de codificación, por lo que se pude decir que es una decisión de arquitectura de la aplicación a ser desarrollada.

El anterior es un ejemplo de una decisión de arquitectura transversal al sistema completo, si bien es cierto muchas de las decisiones de arquitectura son principalmente decisiones transversales al sistema, hay algunas de ellas que afectan a un área específica, el patrón que revisaremos afecta las decisiones que se toman solo en el área particular de la lógica de negocio y como esta se implementa.

Se conoce como lógica de negocio al conjunto de reglas con las cuales un negocio funciona y opera, los sistemas son en general desarrollados en la industria como una herramienta de soporte que ayuda a manejar y automatizar estas reglas en la operación diaria del negocio, uno de los patrones mas utilizados para implementar la lógica de negocio es el patrón Transaction Script, este patrón tiene la ventaja de ser muy simple de implementar y funciona muy bien en escenarios de lógicas de negocio simples.

Antes de describirlo voy a decir que este patrón me carga… pero existe, hay que conocerlo y para ser justo, el problema no es del patrón, si no de los que lo implementan a martillazos en cualquier parte.

El patrón Transaction Script organiza toda la lógica como un solo procedimiento (ojo que no es procedimiento almacenado, es conjunto de instrucciones) y se comunica con la base de datos generando una sola sesión transaccional de comunicación con ella. En la mayoría de los casos este patrón se implementa de tres maneras, como una componente muy simple que orquesta el llamado de uno o una consecución de procedimientos (ahora si procedimientos almacenados), como métodos estáticos que generan lógica para ser ejecutada mediante un ORM en la base o alguna clase de traductor, y (la más fea de las opciones) como generación de una sentencia SQL para ser enviada como transacción a la base (¿quién dijo PHP?, yo los escuché… más respeto por favor). La ventaja de este patrón es que se puede implementar muy rápida y fácilmente, que es conceptualmente muy simple, y se adapta a muchos escenarios. Algunas desventajas son, que se tiende a repetir código en su implementación (aunque no debería tiende a ocurrir), que si el escenario se vuelve complejo el código pierde mantenibilidad y que cuesta separar conceptualmente donde están las responsabilidades de esas transacciones.

Repito nuevamente, no me gusta mucho, creo que hay alternativas mejores, pero funciona y es una alternativa a tomar, para escenarios simples, muy muy simples.