Organizar la lógica de negocio es una de las decisiones más importantes al diseñar software empresarial. El script de transacción es la primera forma de estructurar el dominio que se presenta dentro del contexto de una arquitectura limpia, y entender sus ventajas y limitaciones permite tomar mejores decisiones arquitectónicas desde el inicio.
¿Qué es el script de transacción y cómo organiza la lógica?
El script de transacción organiza la lógica de negocio en procedimientos, donde cada procedimiento maneja una única solicitud proveniente de la capa externa [0:08]. Este patrón está descrito en el libro Patterns of Enterprise Application Architecture de Martin Fowler, una referencia clave para entender cómo estructurar aplicaciones empresariales.
La idea central es sencilla: si necesitas registrar una factura, creas un procedimiento dedicado exclusivamente a esa operación. Todo el flujo se resuelve dentro de ese procedimiento de forma transaccional.
¿Cuáles son las dos formas de organizar los procedimientos?
Existen dos maneras principales de agrupar estos procedimientos [1:15]:
- Jerarquía de herencia: se define una clase base o interfaz llamada transaction script con un método como
run o execute, y luego se crea una clase por cada procedimiento. Por ejemplo, en un sistema de aerolíneas: una clase para búsqueda de vuelos y otra para registro de vuelos. Cada clase tiene una responsabilidad clara y visible.
- Servicio único con múltiples operaciones: un solo servicio agrupa varias operaciones relacionadas con los mismos datos. Funciona bien en aplicaciones pequeñas, pero genera problemas de cohesión rápidamente, ya que las clases tienden a crecer de forma descontrolada [2:08].
La cohesión, en este contexto, se refiere a qué tan relacionado y conectado está lo que una clase manipula. Cuando se pierde cohesión, el código se vuelve difícil de entender y mantener.
¿Cómo se implementa en una arquitectura limpia con Java?
El ejemplo práctico utiliza Java con Maven para ilustrar la estructura [2:42]. La organización del proyecto refleja directamente los elementos de la arquitectura limpia:
- Dominio: contiene el modelo de dominio y la capa de aplicación con sus interfaces y servicios.
- Capa externa: incluye una consola como interfaz de usuario y la capa de persistencia.
Dentro del servicio, que es donde vive la implementación del script de transacción, se inyecta un repositorio como única dependencia externa [3:28]. Esto es importante porque, aunque en implementaciones muy sencillas la persistencia suele mezclarse directamente en el procedimiento, la arquitectura limpia exige mantener esa separación.
¿Cómo funciona una operación dentro del servicio?
El servicio expone un método por cada operación. En el ejemplo, la operación de búsqueda de vuelos [4:07]:
- Recibe parámetros como origen, destino, fecha y número de pasajeros.
- Ejecuta validaciones de entrada de datos.
- Utiliza el repositorio para obtener información.
- Procesa los resultados manipulando una entidad llamada
Flight.
- Retorna el resultado final.
La entidad Flight es un objeto básico con solo atributos, getters y setters, lo que en Java se conoce como POJO (Plain Old Java Object) [4:52]. No contiene operaciones de negocio; toda la lógica reside en el servicio.
¿Cuándo conviene usar el script de transacción y qué problemas presenta?
Este patrón es ideal para aplicaciones con poca lógica de negocio o problemas muy sencillos [5:24]. En casos más elaborados, no se aprovecha el potencial de una arquitectura limpia, que se apoya en un dominio bien organizado capaz de crecer con el tiempo.
Las principales limitaciones son:
- Difícil de mantener: los procedimientos crecen a medida que la lógica se complejiza [5:45].
- Código duplicado: el patrón promueve compartir lo menos posible entre procedimientos, lo que genera repetición.
- No aprovecha la programación orientada a objetos: los métodos viven en el servicio y los datos en la entidad, separados [6:05]. El verdadero poder de la programación orientada a objetos está en combinar datos y comportamiento en un mismo objeto.
Esta separación entre procedimientos y datos es quizás la limitación más significativa, porque convierte el código en algo más cercano a la programación procedural que a un diseño orientado a objetos robusto.
El siguiente paso natural es entender cómo la inyección de dependencias resuelve la conexión entre el servicio y el repositorio que se observó en el ejemplo. ¿Has trabajado con transaction scripts en tus proyectos? Comparte tu experiencia.
