El Transaction Script es una forma de organizar el dominio de una aplicación en procedimientos, donde cada procedimiento maneja una única solicitud de la capa externa. Es útil para aplicaciones con poca lógica de negocio y sirve como punto de partida para entender patrones más avanzados de organización de dominio dentro de una arquitectura limpia.

Este enfoque está documentado en el libro Patterns of Enterprise Application Architecture de Martin Fowler, y aquí lo aterrizamos con un ejemplo en Java para que veas cómo se traduce en código real.

¿Qué es el Transaction Script y cómo organiza la lógica?

La idea central es sencilla: organizas la lógica en procedimientos, y cada procedimiento atiende una operación específica como registrar una factura, buscar un vuelo o actualizar un usuario [0:30].

¿Qué es un Transaction Script? Es un patrón que organiza la lógica de negocio en procedimientos, donde cada procedimiento maneja una solicitud de la capa externa, como registrar una factura o buscar un vuelo.

Hay dos formas comunes de estructurar estos procedimientos en código.

¿Cómo se implementa con jerarquía de herencia?

La primera opción es usar una clase base o interfaz llamada Transaction Script con un único método, que puede llamarse run, execute o ejecutar [1:05]. Después creas una clase por cada procedimiento de tu aplicación.

Por ejemplo, en un sistema de aerolíneas tendrías:

• Una clase para buscar vuelos.
• Una clase para registrar vuelos.
• Una clase por cada operación adicional que necesites.

Esta separación hace muy visible la responsabilidad de cada clase y es una idea recurrente en patrones de dominio que verás más adelante.

¿Cómo se implementa con un servicio único?

La segunda forma agrupa varias operaciones dentro de un mismo servicio, normalmente organizadas por funcionalidad o por los datos que manipulan [1:55]. Si trabajas con vuelos, tendrías un servicio de vuelos con todas las operaciones relacionadas.

Este enfoque funciona en aplicaciones pequeñas, pero rápido empiezas a tener problemas de cohesión, que es qué tan relacionado está lo que manipulas dentro de una misma clase. Las clases tienden a crecer rápido y se vuelven difíciles de mantener.

¿Cómo se ve el Transaction Script en código Java?

El ejemplo está implementado en Java usando Maven para gestionar dependencias [2:35]. La estructura sigue los principios de arquitectura limpia con una separación clara entre dominio y capa externa.

Dentro del dominio encontrarás:

• El modelo de dominio, donde viven las entidades.
• La aplicación, que contiene las interfaces y el servicio.

En la capa externa están la consola que actúa como interfaz de usuario y la persistencia.

¿Qué hace el servicio en este patrón?

El servicio es donde vive la implementación del Transaction Script. Recibe una referencia a un repositorio para acceder a los datos, y eso es lo único que se deja fuera del script [3:40]. En implementaciones muy básicas, hasta la persistencia se mete dentro del procedimiento, pero al trabajar con arquitectura limpia esa no es la ruta.

Dentro del servicio tienes un método por operación. En el ejemplo solo hay uno: buscar vuelos entre un origen y un destino para una fecha específica, verificando disponibilidad para cierto número de pasajeros [4:30]. El método ejecuta validaciones de entrada, usa el repositorio para traer información y luego procesa el resultado.

¿Qué papel juega la entidad Flight?

La entidad flight es un objeto básico con solo atributos y métodos get y set. En otros contextos se le llama POJO o Plain Old Java Object [5:25]. No tiene operaciones, no tiene comportamiento, solo estructura.

Toda la lógica vive en el servicio. Los datos viven en la entidad. Y aquí aparece la grieta más importante de este patrón.

¿Cuándo usar Transaction Script y qué problemas trae?

Este patrón funciona bien cuando tu aplicación tiene poca lógica de negocio o resuelve problemas sencillos [6:10]. En casos más elaborados, no le sacas el jugo a la arquitectura limpia, porque ella se apoya en un dominio bien organizado que pueda crecer con el tiempo.

¿Cuándo conviene usar Transaction Script? Cuando la aplicación tiene poca lógica de negocio o procedimientos sencillos. En sistemas con dominio complejo, este patrón se vuelve difícil de mantener.

Estas son las limitaciones más fuertes que vas a encontrar:

• Difícil de mantener. Los procedimientos crecen conforme la lógica se complica.
• Código duplicado. El patrón promueve compartir lo menos posible entre procedimientos.
• Procedimientos enormes. A mayor complejidad, mayor tamaño de cada método.

Y hay un problema de fondo que es el más importante: no aprovecha la programación orientada a objetos [7:20]. En el ejemplo, el servicio tiene los métodos, pero los datos viven en la entidad flight. Tienes procedimientos por un lado y datos por otro, cuando el verdadero poder de la POO está en mantener ambos juntos en el mismo objeto.

En la siguiente lección vas a ver inyección de dependencias para entender mejor cómo funciona ese repositorio que recibe el servicio. ¿Has aplicado Transaction Script en algún proyecto tuyo? Cuéntame en los comentarios qué tan bien te funcionó.