35. Casos de uso y modelado de dominio
35.1 Introducción
Los casos de uso describen interacciones entre actores y sistema. El modelado de dominio describe los conceptos importantes del negocio y las relaciones entre ellos. Ambos enfoques se complementan.
Un caso de uso puede revelar conceptos como Paciente, Turno, Médico, Agenda, Especialidad, Sede y Confirmación. El modelo de dominio organiza esos conceptos y ayuda a entender cómo se relacionan.
Trabajar con ambos permite evitar especificaciones superficiales. Los casos de uso muestran comportamiento; el modelo de dominio muestra el vocabulario y la estructura conceptual del problema.
35.2 Qué es el modelado de dominio
El modelado de dominio consiste en identificar conceptos relevantes del negocio, sus atributos importantes y sus relaciones. No se trata todavía de diseñar tablas de base de datos ni clases de implementación, sino de comprender el problema.
Por ejemplo, en un sistema de turnos médicos, el dominio incluye pacientes, profesionales, especialidades, agendas, turnos, sedes y horarios disponibles.
35.3 Relación con los casos de uso
Los casos de uso ayudan a descubrir conceptos del dominio porque describen acciones, datos, reglas y resultados. Al leer el flujo principal, las alternativas y las reglas, aparecen sustantivos y relaciones que deben entenderse.
Por ejemplo, si el caso de uso dice "el paciente selecciona un profesional y un horario disponible", aparecen al menos tres conceptos: Paciente, Profesional y Horario disponible.
35.4 Del caso de uso al modelo de dominio
Los conceptos del dominio pueden descubrirse leyendo cuidadosamente los casos de uso. Los sustantivos suelen indicar posibles conceptos; los verbos y reglas ayudan a entender relaciones; las restricciones muestran condiciones importantes del negocio.
35.5 Conceptos que aparecen en un caso de uso
En Solicitar turno, pueden aparecer conceptos como:
- Paciente.
- Turno.
- Médico o Profesional.
- Especialidad.
- Agenda.
- Horario disponible.
- Sede.
- Confirmación.
Estos conceptos pueden formar parte del modelo de dominio si son relevantes para comprender el negocio.
35.6 Relaciones entre conceptos
El modelo de dominio no solo enumera conceptos. También muestra cómo se relacionan.
Ejemplos:
- Un paciente puede tener muchos turnos.
- Un turno corresponde a un profesional.
- Un profesional atiende una o más especialidades.
- Una agenda pertenece a un profesional.
- Una sede contiene consultorios o espacios de atención.
35.7 Reglas de negocio y dominio
Muchas reglas de negocio se entienden mejor cuando existe un modelo de dominio. Por ejemplo, la regla "un médico no puede tener dos turnos en el mismo horario" depende de entender Médico, Turno y Horario.
El modelo de dominio ayuda a precisar esas reglas y a evitar términos ambiguos.
35.8 Vocabulario común
Un beneficio importante del modelado de dominio es construir un vocabulario común. Si usuarios, analistas y desarrolladores usan las mismas palabras con el mismo significado, se reducen errores de comunicación.
Por ejemplo, si "profesional", "médico" y "prestador" se usan como sinónimos o con diferencias, el equipo debe aclararlo. Esa decisión afecta casos de uso, reglas, datos y pantallas.
35.9 Diferencia entre modelo de dominio y base de datos
El modelo de dominio no es necesariamente el modelo de base de datos. Puede inspirar el diseño de datos, pero su objetivo principal es comprender conceptos del negocio.
Una base de datos incluye decisiones técnicas como claves, índices, tablas intermedias y optimizaciones. El modelo de dominio se concentra en significado y relaciones conceptuales.
35.10 Diferencia entre modelo de dominio y clases de software
El modelo de dominio tampoco es automáticamente un diagrama de clases de implementación. Algunos conceptos del dominio pueden convertirse en clases, pero otros pueden representarse de otra manera en el diseño.
La prioridad del modelo de dominio es entender el problema, no definir la solución técnica final.
35.11 Cómo extraer conceptos de un caso de uso
Para extraer conceptos, se puede seguir este método:
- Leer el nombre, resumen y flujo principal.
- Subrayar sustantivos importantes.
- Identificar datos que se registran o consultan.
- Revisar reglas de negocio.
- Buscar relaciones entre conceptos.
- Descartar términos que solo son detalles de interfaz.
- Validar el vocabulario con usuarios del dominio.
35.12 Ejemplo aplicado a Solicitar turno
Fragmento del caso de uso:
Conceptos posibles: Paciente, Especialidad, Fecha, Profesional, Horario disponible, Reserva, Turno y Confirmación.
35.13 Tabla de conceptos
Una tabla inicial de conceptos puede ayudar antes de dibujar el modelo:
| Concepto | Significado | Relaciones posibles |
|---|---|---|
| Paciente | Persona que solicita atención médica. | Tiene turnos. |
| Turno | Reserva de atención en fecha y horario determinados. | Corresponde a un paciente y a un profesional. |
| Profesional | Persona que atiende consultas médicas. | Tiene agenda y especialidades. |
| Agenda | Organización de disponibilidad de un profesional. | Contiene horarios disponibles o bloqueados. |
| Especialidad | Área médica de atención. | Puede estar asociada a profesionales. |
35.14 Casos de uso que revelan atributos
Los casos de uso también ayudan a descubrir atributos de los conceptos. Si el flujo necesita mostrar fecha, hora, sede y profesional, esos datos probablemente son atributos o relaciones importantes del Turno.
Sin embargo, no todos los datos de una pantalla deben convertirse automáticamente en atributos del dominio. Hay que distinguir información esencial del negocio de datos puramente visuales o temporales.
35.15 Casos de uso que revelan estados
Algunos casos de uso muestran estados importantes. Por ejemplo, un Turno puede estar solicitado, confirmado, cancelado, ausente o atendido.
Estos estados pueden aparecer en flujos, reglas y postcondiciones. Identificarlos ayuda a modelar correctamente el ciclo de vida de los conceptos.
35.16 Modelado iterativo
El modelo de dominio se construye de manera iterativa. Al analizar nuevos casos de uso, pueden aparecer conceptos nuevos o relaciones que obligan a ajustar el modelo.
Esto es normal. El modelo mejora a medida que se entienden mejor los procesos y reglas del negocio.
35.17 Errores frecuentes
Al relacionar casos de uso y dominio, suelen aparecer estos errores:
- Crear el modelo de dominio sin leer casos de uso.
- Confundir modelo de dominio con base de datos.
- Confundir conceptos del negocio con componentes técnicos.
- Agregar todos los campos de pantalla como atributos sin criterio.
- No validar términos con usuarios del dominio.
- Usar sinónimos sin aclarar diferencias.
- No actualizar el modelo cuando cambian reglas o casos de uso.
35.18 Lista de revisión
Antes de cerrar una versión del modelo de dominio, conviene revisar:
- ¿Los conceptos aparecen en casos de uso o reglas del negocio?
- ¿Cada concepto tiene un significado claro?
- ¿Las relaciones principales están identificadas?
- ¿Se evitaron detalles técnicos de implementación?
- ¿El vocabulario fue validado con usuarios?
- ¿Los estados importantes están representados o documentados?
- ¿El modelo ayuda a comprender mejor los casos de uso?
35.19 Qué debes recordar de este tema
- Los casos de uso describen comportamiento; el modelo de dominio describe conceptos del negocio.
- Los sustantivos de los casos de uso pueden revelar conceptos del dominio.
- Las reglas de negocio ayudan a descubrir relaciones y restricciones.
- El modelo de dominio no es lo mismo que la base de datos.
- Tampoco es automáticamente el diseño de clases de software.
- Un vocabulario común reduce errores de comunicación.
- Casos de uso y modelo de dominio deben evolucionar juntos.
35.20 Conclusión
Los casos de uso y el modelado de dominio se complementan. Los casos de uso muestran cómo se usa el sistema; el modelo de dominio ayuda a comprender los conceptos que hacen posible ese comportamiento.
Cuando ambos se mantienen coherentes, el análisis gana claridad y el diseño posterior tiene una base más sólida. En el próximo tema estudiaremos la relación entre casos de uso y diseño de clases, servicios y componentes.