1. ¿Qué es el modelado de dominio y por qué es importante?

1.1 Introducción

El modelado de dominio es una actividad de análisis que busca comprender y representar el mundo del problema para el cual se construirá un sistema de software. Antes de hablar de pantallas, bases de datos, clases de programación o tecnología, necesitamos entender qué conceptos existen en el negocio, cómo se relacionan, qué reglas deben cumplirse y qué vocabulario usan las personas que conocen ese dominio.

Un dominio puede ser muy simple o muy complejo. Puede tratarse de turnos médicos, ventas en línea, reservas hoteleras, facturación, logística, educación, banca, seguros, gestión de stock o cualquier otro ámbito donde el software debe resolver necesidades reales. El modelo de dominio nos ayuda a ordenar ese conocimiento para que el equipo no programe sobre supuestos confusos.

Este curso parte de lo ya visto en Introducción a la Ingeniería de Software, Requerimientos de Software, Casos de uso y Diagramas UML. En esos cursos se analizaron necesidades, actores, escenarios y formas de representar sistemas. Ahora nos enfocaremos en el corazón conceptual del problema: el dominio.

1.2 Una definición simple

Podemos definir el modelado de dominio de la siguiente manera:

Esta definición contiene varias ideas importantes:

• Representación organizada: el conocimiento del negocio se estructura para que pueda ser entendido, discutido y validado.
• Conceptos: aparecen elementos significativos del dominio, como Cliente, Turno, Pedido, Factura, Producto, Cuenta o Reserva.
• Relaciones: los conceptos no viven aislados; se vinculan entre sí de distintas formas.
• Reglas: el dominio impone condiciones, restricciones, cálculos y decisiones que el software deberá respetar.
• Independencia técnica: el modelo de dominio no debe comenzar pensando en tablas, pantallas, endpoints o frameworks.

1.3 Modelo de dominio como puente entre negocio y software

1.4 Qué representa un modelo de dominio

Un modelo de dominio representa los elementos importantes del negocio y el significado que tienen dentro de un contexto. No se limita a listar datos. También muestra relaciones, restricciones, estados posibles, eventos relevantes y reglas que explican cómo funciona el dominio.

Por ejemplo, en un sistema de gestión de turnos, el dominio puede incluir conceptos como Paciente, Profesional, Especialidad, Agenda, Turno y Cancelación. Pero el modelo no se queda en los nombres: también debe expresar que un turno pertenece a una agenda, que una agenda corresponde a un profesional, que un paciente puede reservar más de un turno, que un turno no puede reservarse si el horario ya está ocupado y que una cancelación puede tener una política de anticipación mínima.

El valor del modelo está en hacer explícito ese conocimiento. Muchas reglas no aparecen completas en una primera entrevista. Surgen al preguntar, al revisar casos de uso, al analizar excepciones y al validar ejemplos concretos con quienes conocen el negocio.

1.5 Qué no es un modelo de dominio

Para evitar confusiones, conviene aclarar qué no es un modelo de dominio. No es una base de datos, aunque luego pueda ayudar a diseñarla. No es una interfaz de usuario, aunque pueda orientar qué información debe mostrarse. No es una lista de clases de programación, aunque pueda influir en el diseño orientado a objetos. No es un diagrama decorativo, porque debe servir para razonar y tomar decisiones.

El modelo de dominio debe enfocarse primero en el problema, no en la implementación. Si en una etapa inicial aparecen conceptos como TablaTurnos, ControladorTurnos, TurnoDTO o PantallaReserva, probablemente el modelo está mezclando el dominio con detalles técnicos. Esos elementos pueden ser necesarios en el diseño del software, pero no explican cómo funciona el negocio.

1.6 Por qué es importante modelar el dominio

Muchos problemas de software no nacen por falta de programación, sino por falta de comprensión del problema. Un equipo puede escribir código correcto desde el punto de vista técnico y aun así entregar un sistema que no respeta reglas importantes, usa nombres confusos, mezcla responsabilidades o no representa adecuadamente el trabajo real de los usuarios.

El modelado de dominio reduce ese riesgo porque obliga a conversar, nombrar, ordenar y validar. Cuando el equipo construye un modelo, aparecen preguntas que quizás no estaban claras en los requerimientos: ¿qué diferencia hay entre cliente y usuario?, ¿un pedido puede existir sin pago?, ¿una reserva vencida se elimina o cambia de estado?, ¿qué ocurre si una factura se anula?, ¿quién puede modificar una agenda?, ¿qué significa exactamente "turno disponible"?

Responder estas preguntas temprano evita errores costosos. Cuanto más tarde se descubre una regla mal entendida, más caro suele ser corregir pantallas, datos, validaciones, pruebas, documentación y decisiones de diseño.

1.7 El dominio como lenguaje compartido

Uno de los aportes más importantes del modelado de dominio es construir un lenguaje compartido. Usuarios, analistas, desarrolladores, testers y responsables del negocio deberían poder hablar de los conceptos principales usando nombres claros y consistentes.

Si una misma idea recibe varios nombres, el proyecto empieza a acumular ambigüedad. Por ejemplo, en un sistema se puede hablar de "cliente", "paciente", "persona atendida" y "usuario" como si fueran lo mismo, cuando quizás no lo son. En otro caso, "pedido", "orden" y "solicitud" pueden tener diferencias importantes. El modelo de dominio ayuda a decidir qué significa cada término y en qué contexto se usa.

Este lenguaje común después aparece en casos de uso, reglas de negocio, pruebas, documentación, conversaciones de planificación e incluso en el código. Cuanto más coherente sea el vocabulario, menor será la distancia entre lo que el negocio espera y lo que el equipo implementa.

1.8 Relación con los requerimientos

Los requerimientos indican qué necesita el sistema y bajo qué condiciones. El modelo de dominio ayuda a entender los conceptos sobre los cuales esos requerimientos operan. Por ejemplo, un requerimiento puede decir: "El paciente debe poder cancelar un turno con al menos 24 horas de anticipación". El modelo de dominio permite identificar conceptos como Paciente, Turno y Cancelación, además de una regla relacionada con el tiempo mínimo de anticipación.

Los requerimientos suelen expresar necesidades, restricciones y expectativas. El modelo de dominio transforma parte de esa información en una estructura conceptual. Así, los requerimientos no quedan como frases aisladas, sino conectados con los elementos del negocio que deben existir y comportarse de determinada manera.

1.9 Relación con los casos de uso

Los casos de uso describen interacciones entre actores y sistema para lograr objetivos. El modelo de dominio identifica los conceptos que participan en esas interacciones. Si un caso de uso se llama "Reservar turno", probablemente aparecerán conceptos como Paciente, Profesional, Agenda, Turno, Horario disponible y Confirmación.

Cada escenario de un caso de uso puede revelar nuevas reglas o relaciones. Por ejemplo, un flujo alternativo puede indicar que no hay horarios disponibles, que el paciente tiene una deuda pendiente o que el profesional no atiende cierta especialidad. Esos detalles pueden enriquecer el modelo de dominio porque muestran restricciones reales del negocio.

Por eso, casos de uso y modelo de dominio se complementan. Los casos de uso muestran objetivos y pasos; el modelo de dominio muestra los conceptos y reglas que hacen posible esos pasos.

1.10 Relación con UML

UML puede utilizarse para representar modelos de dominio, especialmente mediante diagramas de clases conceptuales. En ese tipo de diagrama, las clases no representan necesariamente clases de programación, sino conceptos del dominio. Las asociaciones muestran relaciones de significado y las multiplicidades ayudan a expresar restricciones de cantidad.

También pueden usarse otros diagramas UML cuando aportan claridad. Un diagrama de estados puede representar el ciclo de vida de un Turno, un Pedido o una Factura. Un diagrama de actividades puede mostrar un proceso de negocio. Un diagrama de objetos puede mostrar ejemplos concretos del modelo con instancias reales o ficticias.

La clave está en usar UML como herramienta de comunicación, no como fin en sí mismo. El objetivo no es dibujar por dibujar, sino comprender mejor el dominio.

1.11 Modelo de dominio y diseño del software

Un buen modelo de dominio influye en el diseño del software, pero no es exactamente lo mismo. Durante el análisis, buscamos entender el negocio. Durante el diseño, decidimos cómo convertir ese conocimiento en componentes, clases, módulos, interfaces, bases de datos y servicios concretos.

Si el modelo de dominio está bien trabajado, el diseño suele ser más claro. Los nombres son más precisos, las responsabilidades se ubican mejor y las reglas importantes no quedan dispersas en lugares accidentales. En cambio, cuando el dominio no se entiende, es común que el código termine mezclando conceptos, duplicando validaciones o escondiendo reglas de negocio en pantallas, consultas SQL o controladores.

El modelo de dominio no garantiza automáticamente un buen diseño, pero crea una base conceptual más sólida para tomar decisiones técnicas.

1.12 Ejemplo inicial: sistema de turnos

Supongamos que debemos construir un sistema de gestión de turnos para un consultorio. Si comenzamos pensando solo en pantallas, podríamos listar: pantalla de inicio, pantalla de profesionales, pantalla de reserva y pantalla de cancelación. Esa información puede ser útil, pero todavía no explica el dominio.

Al modelar el dominio, aparecen preguntas más profundas: ¿qué es un turno?, ¿qué estados puede tener?, ¿quién puede reservarlo?, ¿qué relación hay entre profesional y especialidad?, ¿cómo se define la disponibilidad?, ¿qué ocurre cuando un paciente cancela?, ¿un turno cancelado puede volver a ofrecerse?, ¿qué regla se aplica si el paciente no asiste?

Un primer modelo podría incluir Paciente, Profesional, Especialidad, Agenda, Franja horaria, Turno y Cancelación. Luego, al validar con expertos, quizás descubramos que también necesitamos Ausencia del profesional, Sobreturno, Obra social, Motivo de consulta o Confirmación previa. El modelo evoluciona a medida que el conocimiento mejora.

1.13 Beneficios principales

El modelado de dominio aporta beneficios concretos durante el desarrollo de software:

• Mejor comprensión del problema: el equipo entiende qué conceptos existen y qué significan.
• Menos ambigüedad: se reducen interpretaciones diferentes sobre las mismas palabras.
• Detección temprana de reglas: aparecen restricciones que podrían pasar inadvertidas.
• Comunicación más clara: usuarios y equipo técnico pueden revisar el modelo con un vocabulario común.
• Diseño más coherente: las decisiones técnicas se apoyan en una comprensión más precisa del dominio.
• Mejor base para pruebas: las reglas y estados del dominio ayudan a definir casos de prueba significativos.
• Documentación útil: el modelo puede convertirse en una referencia para mantenimiento y evolución.

1.14 Riesgos de no modelar el dominio

Cuando el dominio no se modela, el conocimiento queda disperso en conversaciones, documentos incompletos, pantallas, código y memoria de algunas personas. Esto produce dependencia excesiva de individuos, dificultad para incorporar nuevos integrantes y mayor probabilidad de errores al modificar el sistema.

También es frecuente que se implementen soluciones técnicamente correctas pero conceptualmente débiles. Por ejemplo, usar el mismo concepto para representar cosas distintas, permitir estados imposibles, aceptar operaciones que violan reglas del negocio o guardar datos sin entender qué significan.

1.15 Errores frecuentes al comenzar

Al iniciar el modelado de dominio suelen aparecer algunos errores:

• Confundir conceptos del negocio con tablas de base de datos.
• Nombrar elementos con términos técnicos que los usuarios del negocio no usan.
• Agregar atributos sin preguntarse si son relevantes para el dominio.
• Representar pantallas o formularios en lugar de conceptos del negocio.
• Crear modelos demasiado grandes que nadie puede revisar con facilidad.
• Ignorar reglas, estados y eventos, quedándose solo con nombres de entidades.
• No validar el modelo con ejemplos concretos y casos excepcionales.

1.16 Qué debes recordar de este tema

• El modelado de dominio busca comprender y representar el problema antes de diseñar la solución técnica.
• Un modelo de dominio incluye conceptos, relaciones, reglas, estados, eventos y vocabulario del negocio.
• No es lo mismo que una base de datos, una pantalla o una lista de clases de programación.
• Ayuda a reducir ambigüedad y a construir un lenguaje compartido entre negocio y equipo técnico.
• Se relaciona directamente con requerimientos, casos de uso y diagramas UML.
• Un buen modelo de dominio mejora la comunicación, la validación, el diseño, las pruebas y el mantenimiento.
• El modelo debe evolucionar a medida que el equipo aprende más sobre el dominio.

1.17 Conclusión

El modelado de dominio es una práctica fundamental para construir software que responda correctamente a las necesidades del negocio. Su propósito no es producir dibujos formales sin utilidad, sino hacer visible el conocimiento importante del dominio para que pueda ser discutido, validado y usado como base de decisiones posteriores.

En este primer tema vimos qué es el modelado de dominio, qué representa, por qué es importante y cómo se conecta con los cursos anteriores. En el próximo tema profundizaremos en la diferencia entre el dominio del problema y la solución técnica, una distinción clave para evitar modelos mezclados y decisiones prematuras.