34. Caso práctico: modelado de dominio de un sistema de gestión de turnos

34.1 Introducción

En este último tema aplicaremos lo aprendido a un caso práctico: un sistema de gestión de turnos para una clínica o centro de atención. El objetivo no es diseñar pantallas ni tablas, sino construir un modelo de dominio claro que permita comprender conceptos, reglas, estados, eventos y límites de consistencia.

El caso integra vocabulario, entidades, objetos de valor, asociaciones, multiplicidades, reglas de negocio, invariantes, estados, eventos, agregados, contextos delimitados y validación con escenarios.

34.2 Imagen integradora del caso práctico

34.3 Descripción inicial del problema

La clínica necesita administrar turnos para distintos profesionales y especialidades. Los pacientes pueden consultar disponibilidad, reservar turnos, confirmarlos o cancelarlos. Los profesionales tienen agendas con franjas horarias. Algunas franjas pueden bloquearse por ausencia, feriados, reuniones o mantenimiento.

Además, la clínica quiere registrar inasistencias, aplicar políticas de cancelación, notificar recordatorios y mantener información útil para facturación cuando un turno fue atendido.

34.4 Lenguaje ubicuo inicial

Un primer vocabulario del dominio puede incluir:

Cada término debe validarse con expertos. Por ejemplo, debemos decidir si Reserva y Turno son sinónimos o conceptos distintos. También debemos definir qué significa exactamente "turno disponible" y qué diferencia hay entre "cancelado" y "ausente".

34.5 Conceptos principales

Un primer modelo puede contener estos conceptos:

• Paciente: persona que solicita o recibe atención.
• Profesional: persona que atiende turnos de una o varias especialidades.
• Especialidad: área de atención, como cardiología, dermatología o clínica médica.
• Agenda: organización de franjas horarias de un profesional.
• Franja horaria: período disponible, bloqueado o reservado.
• Turno: asignación de una franja a un paciente para una atención.
• Cancelación: registro de la anulación de un turno.

34.6 Entidades y objetos de valor

Paciente, Profesional, Agenda y Turno son buenas candidatas a entidades porque tienen identidad y continuidad. Un paciente conserva identidad aunque cambie su teléfono. Un turno puede cambiar de estado y seguir siendo el mismo turno, según la política del negocio.

Franja horaria puede modelarse como objeto de valor si solo representa fecha, hora de inicio y hora de fin. Pero si la clínica necesita identificarla, bloquearla, reservarla y llevar historial propio, puede convertirse en entidad interna de Agenda.

Otros objetos de valor posibles son Rango horario, Documento, Correo electrónico, Teléfono y Motivo de cancelación, si tienen reglas propias.

34.7 Asociaciones y multiplicidades

Algunas asociaciones iniciales son:

• Paciente reserva Turno.
• Turno pertenece a Agenda.
• Agenda contiene Franjas horarias.
• Profesional posee Agenda.
• Profesional atiende Especialidad.
• Turno puede tener Cancelación.

Las multiplicidades deben validarse. Un paciente puede tener muchos turnos históricos, pero quizá solo uno pendiente por especialidad. Un profesional puede tener una o varias agendas según sede, período o modalidad.

34.8 Reglas de negocio principales

Algunas reglas posibles son:

• Un turno no puede reservarse si la franja horaria ya está ocupada.
• Un paciente no puede tener más de un turno pendiente para la misma especialidad, salvo autorización.
• Una cancelación debe realizarse con al menos 24 horas de anticipación para no registrar inasistencia.
• Una agenda publicada debe tener al menos una franja horaria válida.
• Dos franjas de una misma agenda no pueden superponerse.
• Un turno atendido no puede cancelarse como turno pendiente.

34.9 Estados de Turno

Un ciclo de vida posible para Turno es:

Con alternativas:

La clínica debe validar si necesita estados adicionales, como Reprogramado, Vencido, En espera o Sobreturno.

34.10 Eventos de dominio

Los eventos importantes pueden ser:

• Turno reservado.
• Turno confirmado.
• Turno cancelado.
• Paciente ausente registrado.
• Agenda publicada.
• Franja horaria bloqueada.
• Turno atendido.

Estos eventos pueden disparar consecuencias: enviar notificaciones, liberar franjas, registrar historial, actualizar estadísticas o informar a facturación.

34.11 Agregado Agenda

Agenda puede ser raíz de un agregado que controla Franjas horarias y Bloqueos. Su responsabilidad principal es proteger la consistencia de disponibilidad.

Invariantes posibles del agregado Agenda:

• Las franjas de una misma agenda no deben superponerse.
• Una agenda publicada debe tener al menos una franja válida.
• No se puede agregar una franja fuera del período de vigencia de la agenda.
• Una franja bloqueada no debe ofrecerse como disponible.

34.12 Agregado Turno

Turno puede ser otro agregado o entidad raíz, según el tamaño del dominio. Debe controlar sus estados y transiciones. Por ejemplo, no debería permitir cancelación si ya fue atendido.

También debe registrar eventos relevantes, como Turno reservado o Turno cancelado. Si la cancelación tiene datos propios, como motivo, fecha y responsable, puede modelarse como concepto asociado.

34.13 Servicios de dominio

Algunas operaciones no pertenecen naturalmente a una sola entidad. Por ejemplo:

• Calculador de disponibilidad: combina agenda, turnos existentes, duración, bloqueos y especialidad.
• Política de cancelación: decide si la cancelación es válida y si genera inasistencia.
• Asignador de turnos: selecciona profesional o franja según criterios del negocio.

Estos servicios deben expresar reglas del dominio, no detalles técnicos de infraestructura.

34.14 Contextos delimitados

En un sistema más amplio, pueden separarse contextos:

• Turnos: disponibilidad, reserva, cancelación y confirmación.
• Atención médica: consulta, diagnóstico, evolución e historia clínica.
• Facturación: prestaciones, importes, pagos y comprobantes.
• Notificaciones: recordatorios, avisos y mensajes.
• Administración de pacientes: datos personales y cobertura.

Separar contextos evita que Turno tenga que contener todos los significados administrativos, clínicos y contables a la vez.

34.15 Representación conceptual resumida

Un modelo conceptual resumido podría leerse así:

Este resumen debe complementarse con multiplicidades, reglas e invariantes.

34.16 Escenarios de validación

Algunos escenarios para validar el modelo son:

• Paciente reserva un turno disponible.
• Paciente intenta reservar una franja ya ocupada.
• Paciente cancela con más de 24 horas de anticipación.
• Paciente cancela fuera de término y se registra inasistencia.
• Profesional bloquea una franja de su agenda.
• Agenda intenta publicar franjas superpuestas.
• Paciente no asiste a un turno confirmado.

34.17 Tabla de decisiones del caso

34.18 Checklist final aplicado

Antes de considerar aceptable el modelo, deberíamos revisar:

• ¿Los expertos reconocen el vocabulario?
• ¿Reserva, Turno y Franja horaria están claramente diferenciados?
• ¿Las reglas de cancelación y disponibilidad están visibles?
• ¿Los estados del turno están validados?
• ¿Los agregados protegen invariantes reales?
• ¿Los eventos importantes tienen consecuencias claras?
• ¿El modelo fue probado con escenarios y contraejemplos?

34.19 Qué debes recordar de este caso

• El modelo de dominio empieza con vocabulario y comprensión del negocio.
• Los conceptos deben validarse antes de transformarse en diseño técnico.
• Las reglas de disponibilidad, cancelación y estados son centrales en un sistema de turnos.
• Agenda y Turno pueden tener responsabilidades diferentes.
• Los eventos permiten conectar turnos con notificaciones, atención médica y facturación.
• Los contextos delimitados evitan mezclar significados de distintas áreas.
• La validación con escenarios es indispensable para detectar errores.

34.20 Conclusión

Este caso práctico mostró cómo integrar las ideas principales del curso en un dominio concreto. Modelar un sistema de turnos no consiste solo en dibujar Paciente, Profesional y Turno. Requiere comprender reglas de disponibilidad, estados, eventos, cancelaciones, agregados, contextos y escenarios reales.

Un buen modelo de dominio ayuda a conversar con expertos, validar conocimiento, orientar el diseño y reducir errores antes de construir la solución técnica. Con esto cerramos el curso de Modelado de dominio.