Creación de Service Object para Gestión de Estados de Tareas en Rails

Contenido del curso

Introducción

Pruebas

Interacción dinámica

Notificaciones

Ciclos de vida

Cierre

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:008:37

Creación de Service Object para Gestión de Estados de Tareas en Rails

Curso Intermedio de Ruby on Rails

Clase 30 de 34

Clase 30 / 34

Recursos

Separar la lógica de cambio de estado de una tarea en un Service Object dedicado es una práctica que prepara tu aplicación para crecer sin acumular complejidad dentro de los modelos. Aquí se construye paso a paso el servicio Task::TriggerEvent, desde la prueba hasta la implementación, aplicando metaprogramación de Ruby y respetando el flujo TDD.

¿Por qué crear un Service Object intermedio para cambiar estados?

Cuando componentes externos de Rails necesitan modificar el estado de una tarea, acceder directamente al modelo genera acoplamiento. Un Service Object actúa como barrera intermedia que expone una interfaz clara y controlada. Aunque la lógica inicial parezca mínima, este patrón habilita el escalamiento futuro: políticas de seguridad, políticas de acceso, inyección de dependencias con otros servicios y conexiones adicionales pueden incorporarse sin tocar el modelo.

Facilita la fragmentación de responsabilidades.
Prepara el sistema para recibir security policies y validaciones extra.
Permite inyectar dependencias con otros servicios de forma ordenada.

¿Cómo escribir la prueba del servicio TriggerEvent?

Siguiendo TDD, lo primero es crear el archivo de especificación. Dentro de spec/services/task/, se duplica el archivo send_email_spec.rb y se renombra a trigger_event_spec.rb [01:15].

¿Qué elementos necesita la prueba?

El servicio recibe dos parámetros: la referencia a la tarea y el nombre del evento que se quiere disparar. En la prueba se define una variable let(:event) con el valor start [02:30]. El subject se construye con described_class.new pasando task y event.

Dentro del contexto with a valid task, se persiste la tarea y luego se evalúan tres expectativas:

Que success sea verdadero.
Que task.status sea igual a inprocess después de disparar el evento start [03:18].
Que el conteo de transiciones (task.transitions.count) sea igual a 1, porque cada cambio de estado debe generar un registro de transición [03:45].

¿Cómo se estructura el servicio TriggerEvent?

El archivo se crea en app/services/task/ duplicando send_email.rb y renombrándolo a trigger_event.rb [04:10]. El nombre de la clase debe coincidir exactamente con el que aparece en la cabecera de la prueba: Task::TriggerEvent.

El servicio define dos campos de entrada: task y event, cumpliendo con la llamada uniforme que se espera de todo Service Object en el proyecto.

¿Cómo funciona la metaprogramación en el lanzamiento del evento?

La parte central del método call utiliza metaprogramación de Ruby para invocar dinámicamente el evento sobre la tarea [05:02]. En lugar de escribir manualmente cada transición posible, se construye la llamada así:

ruby task.send("#{event}!")

Si el valor de event es start, esta línea equivale a:

ruby task.start!

El bang (!) al final se agrega mediante interpolación de cadena. Esta técnica permite que un único servicio maneje cualquier evento definido en la máquina de estados sin necesidad de condicionales adicionales. Ruby permite enviar mensajes dinámicos a objetos mediante send, y eso es precisamente lo que se aprovecha aquí.

¿Por qué algo tan simple justifica un servicio?

Aunque el cuerpo del método parece trivial, el servicio se convierte en el punto de entrada oficial para toda transición de estado [05:45]. En un escenario real se podrían agregar:

Políticas de seguridad que validen permisos del usuario.
Políticas de acceso que restrinjan qué roles pueden disparar ciertos eventos.
Conexiones con otros servicios que ejecuten acciones colaterales como notificaciones o auditoría.

Sin el Service Object, toda esa lógica terminaría contaminando el modelo o los controladores.

Finalmente, la ejecución de la prueba se realiza desde la consola con el comando rspec [06:30]. El resultado muestra Task::TriggerEvent#call pasando correctamente, confirmando que el servicio dispara el evento, actualiza el estado y registra la transición.

¿Te animas a crear un Service Object similar para generar el código de la tarea después de su creación? Comparte tu implementación y veamos cómo lo resuelves.

Resumen

¿Por qué crear un Service Object intermedio para cambiar estados?

Facilita la fragmentación de responsabilidades.
Prepara el sistema para recibir security policies y validaciones extra.
Permite inyectar dependencias con otros servicios de forma ordenada.

¿Cómo escribir la prueba del servicio TriggerEvent?

Siguiendo TDD, lo primero es crear el archivo de especificación. Dentro de spec/services/task/, se duplica el archivo send_email_spec.rb y se renombra a trigger_event_spec.rb [01:15].

¿Qué elementos necesita la prueba?

Dentro del contexto with a valid task, se persiste la tarea y luego se evalúan tres expectativas:

Que success sea verdadero.
Que task.status sea igual a inprocess después de disparar el evento start [03:18].
Que el conteo de transiciones (task.transitions.count) sea igual a 1, porque cada cambio de estado debe generar un registro de transición [03:45].

¿Cómo se estructura el servicio TriggerEvent?

El servicio define dos campos de entrada: task y event, cumpliendo con la llamada uniforme que se espera de todo Service Object en el proyecto.

¿Cómo funciona la metaprogramación en el lanzamiento del evento?

ruby task.send("#{event}!")

Si el valor de event es start, esta línea equivale a:

ruby task.start!

¿Por qué algo tan simple justifica un servicio?

Aunque el cuerpo del método parece trivial, el servicio se convierte en el punto de entrada oficial para toda transición de estado [05:45]. En un escenario real se podrían agregar:

Políticas de seguridad que validen permisos del usuario.
Políticas de acceso que restrinjan qué roles pueden disparar ciertos eventos.
Conexiones con otros servicios que ejecuten acciones colaterales como notificaciones o auditoría.

Sin el Service Object, toda esa lógica terminaría contaminando el modelo o los controladores.

¿Te animas a crear un Service Object similar para generar el código de la tarea después de su creación? Comparte tu implementación y veamos cómo lo resuelves.

Introducción

Curso Intermedio de Ruby on Rails: Migración y Optimización Avanzada

Migración de Rails a MongoDB con Mongoid y Pruebas Automatizadas

Gestión de Múltiples Versiones de MongoDB en Linux

Migración de Rails a MongoDB con Mongoid: Configuración Inicial

Migración de Modelos de Active Record a Mongoid

Migración completa de aplicaciones con MongoDB y Rails

Pruebas

Pruebas Automatizadas: Introducción a TDD y BDD en Desarrollo de Software

Creación de Fábricas Automatizadas con FactoryBot y Faker en Rails

Integración de Librerías para Pruebas Automatizadas en Rails

Pruebas de Modelos en Rails con Mongoid y RSpec

Pruebas de Validación y Guardado en Modelos Rails

Validación y Pruebas de Modelos en Ruby on Rails

Pruebas de Integración en Rails: Configuración y Ejecución Básica

Creación y prueba de tareas con métodos POST en Rails

Automatización de Pruebas con Headless Browser y Capybara en Rails

Pruebas de Sistema con KPIBara y WebDriver en Rails

Automatización de Pruebas de Sistema con Selenium y JavaScript

Interacción dinámica

Uso de CoffeeScript con Rails y Webpacker: Integración y Ejemplos

Integración de Selectize con RAILs y Webpacker

Formularios Anidados en Rails: Uso de Simple Form y Cocoon

Implementación Selectize en Formularios Dinámicos con Kokoon y CafeScript

Notificaciones

Envío de Emails Automático al Crear Tareas

Introducción a Service Objects en Ruby on Rails

Pruebas de TDD para Service Object de Notificaciones por Correo

Creación de Service Objects para Envío de Correos en Ruby on Rails

Procesos en Background con Sucker Punch en Rails

Pruebas con Doubles en Rails usando Sucker Punch

Ciclos de vida

Máquinas de Estado Finito: Conceptos y Aplicaciones Prácticas

Creación de Máquinas de Estados con AASM en Ruby on Rails

Creación de Service Object para Gestión de Estados de Tareas en Rails

Acciones de Controlador y Pruebas en Ruby on Rails

Integración de AJAX en Gestión de Estados de Tareas en Ruby on Rails

Cierre

Optimización de rendimiento en aplicaciones web con Ruby on Rails

Migración y Pruebas Automatizadas en Ruby on Rails

Creación de Service Object para Gestión de Estados de Tareas en Rails