Modelo de dominio: las cosas que el sistema debe recordar
EventoUAB ya tiene historias priorizadas y un diagrama de casos de uso con quién hace qué. Antes de decidir cómo se guarda o se programa algo, el equipo necesita ponerse de acuerdo en el vocabulario: qué cosas existen en el negocio (Club, Espacio, Reserva), qué se sabe de cada una y cómo se conectan. Esta guía enseña a armar ese modelo, con entidades, atributos y multiplicidad, a partir de los casos de uso que ya tenés.
Bienvenido
Ya sabemos quién usa EventoUAB y para qué. Falta otra pregunta: ¿qué cosas tiene que recordar el sistema? Un modelo de dominio responde con un diagrama del vocabulario del negocio: las cosas que importan (entidades), qué se sabe de cada una (atributos) y cómo se conectan (relaciones).
Al finalizar esta guía sabrás sacar entidades candidatas de un caso de uso, distinguir entidades de atributos y de piezas del software, leer y escribir la multiplicidad de una relación, y decidir cuándo algo merece ser una entidad propia.
Encontrarás actividades cortas y autocorregibles —selección múltiple, clasificación, emparejamiento y completar espacios— repartidas a lo largo de la guía, y una sección de ejercicios de razonamiento donde se te da un escenario y debés predecir la respuesta antes de comprobarla.
El modelo de dominio es una conversación con el negocio, no un diseño técnico. Por eso no tiene claves foráneas, ni tipos de datos, ni métodos: Bienestar Estudiantil tendría que poder leerlo sin ayuda.
📦 Entidades
Las cosas del negocio que se necesita recordar y distinguir una de otra.
🏷️ Atributos
Los datos simples que describen a cada entidad.
🔗 Relaciones
Cómo se conectan las entidades y cuántas de cada lado.
Entidades: buscar sustantivos y filtrar
Una forma práctica de empezar es tomar un caso de uso, subrayar todos sus sustantivos y decidir, uno por uno, qué es cada cosa. Tomemos el flujo de "Reservar espacio" de la guía anterior.
| Candidato | Decisión | Por qué |
|---|---|---|
| Club | Entidad | El negocio necesita recordar qué club reservó. |
| Espacio | Entidad | Hay varios y hay que distinguir uno de otro. |
| Reserva | Entidad | Es el hecho central: un club ocupó un espacio en un horario. |
| Fecha, hora | Atributo | Describen a la reserva; no se recuerdan por sí solos. |
| Sistema, botón, base de datos | Fuera del dominio | Son piezas del software, no conceptos del negocio. |
1. ¿El negocio necesita recordar esta cosa y distinguirla de otras del mismo tipo? Si sí, es una entidad. 2. ¿Es solo un dato que describe a otra cosa? Entonces es un atributo. Si es una pieza del software, no pertenece al modelo de dominio.
¿Qué es cada elemento dentro del análisis de EventoUAB?
Atributos: qué guarda cada entidad
Los atributos son los datos simples que describen a una entidad: texto, número, fecha o sí/no. Cada atributo tiene que salir de algo que el negocio realmente usa, no de lo que "podría hacer falta algún día".
| Entidad | Atributos | Pregunta del negocio que responde |
|---|---|---|
| Espacio | nombre, capacidad, tieneProyector | ¿Cuál es y cuánta gente entra? |
| Club | nombre, facultad | ¿Qué club es y a qué facultad pertenece? |
| Reserva | fecha, horaInicio, horaFin, estado | ¿Cuándo es y en qué situación está? |
| Estudiante | nombre, carnet, correo | ¿Quién es y cómo se lo contacta? |
Listas de otras entidades (un Club no tiene un atributo "reservas": eso es una relación). Datos que se calculan (la duración sale de horaInicio y horaFin). Claves técnicas (club_id o espacio_id son un asunto de la base de datos, no del negocio).
Un compañero escribe en la entidad Club el atributo "reservas" (una lista de las reservas del club). ¿Qué corresponde hacer?
Relaciones y multiplicidad
Una relación conecta dos entidades con un verbo, y la multiplicidad dice cuántas de cada lado participan. Se lee en los dos sentidos.
| Notación | Significa | En EventoUAB |
|---|---|---|
| 1 | Exactamente uno. | Cada Reserva ocupa un solo Espacio. |
| 0..1 | Cero o uno (opcional). | Un Club podría tener a lo sumo un asesor asignado. |
| 0..* | Cero o muchos. | Un Club puede tener ninguna o muchas Reservas. |
| 1..* | Uno o más (al menos uno). | Un evento exige al menos un responsable presente. |
De izquierda a derecha: un Club solicita cero o muchas Reservas. De derecha a izquierda: una Reserva es solicitada por exactamente un Club. Si una de las dos lecturas suena rara para el negocio, la multiplicidad está mal.
1. Un Club puede tener .
2. Cada Reserva ocupa .
3. Si el negocio exige que toda Reserva tenga un Club, del lado Club la multiplicidad es .
4. Un Espacio nuevo, sin ninguna reserva todavía, es válido porque del lado Reserva la multiplicidad es .
Si un Estudiante puede ser miembro de varios Clubes y un Club tiene varios miembros, la relación es 0..* de ambos lados. Cuando esa relación guarda datos propios (por ejemplo, la fecha de ingreso), conviene convertirla en una entidad intermedia, como Membresía. Lo verás en los ejercicios de abajo.
¿Atributo o entidad? La decisión más común
El caso de uso de la guía anterior tenía un «extend»: Pedir proyector o sonido. Eso plantea una pregunta de modelado: ¿el proyector es un atributo de Espacio (tieneProyector) o una entidad propia (Equipo)?
| Si... | Entonces conviene |
|---|---|
| Solo importa saber si existe o no, y no cambia por reserva. | Atributo (tieneProyector: sí/no). |
| Hay varios, se cuentan, se asignan a una reserva o tienen datos propios. | Entidad propia (Equipo, relacionada con Reserva). |
Como el estudiante puede pedir un proyector al reservar, no basta con un sí/no en el Espacio: el pedido depende de la Reserva. Cuando el modelo tiene que recordar "qué equipo se usó en cuál reserva", ya no es un atributo.
Ejercicios de razonamiento
Cada ejercicio presenta un escenario. Antes de elegir, pensá la respuesta y recién después comparala con las opciones.
Bienestar quiere saber cuántos proyectores hay y en qué reservas se usa cada uno. ¿Cómo se modela el proyector?
Un estudiante puede ser miembro de varios Clubes y cada Club tiene varios miembros. Además se quiere guardar la fecha en que cada estudiante ingresó. ¿Qué modelo corresponde?
Historia: "Como Bienestar, quiero ver el historial de reservas de un espacio". ¿Qué tiene que existir en el modelo para poder responderla?
Un concepto, cuatro vistas
El modelo de dominio es una vista más de EventoUAB, y cada vista responde una pregunta distinta. Confundirlas es el error más frecuente: por eso el modelo de dominio no lleva claves ni métodos.
Une cada vista con la pregunta que responde.
Si le pedís a una IA "armá la base de datos de EventoUAB" sin darle el modelo de dominio, inventa nombres y relaciones a su manera. Con las entidades, atributos y multiplicidades escritos, el resultado ya está acotado: no puede inventar un "Evento" que nadie definió.
Actividades de repaso
Un repaso integrador de todo el módulo. Cada actividad se corrige al instante; tu progreso se guarda automáticamente en este navegador.
Un modelo de dominio bien hecho incluye las claves foráneas (como club_id) para que se vea cómo se conectan las entidades.
¿Cuál de estos elementos es una entidad del modelo de dominio de EventoUAB?
En la relación Club–Reserva leída de Reserva a Club ("cada Reserva es solicitada por…"), ¿qué multiplicidad refleja la regla de que no hay reservas sin club?
Un modelo de dominio tiene la entidad Reserva con el atributo "duracion" guardado junto a horaInicio y horaFin. ¿Qué observación corresponde?
Cheat Sheet
| Término | Idea clave |
|---|---|
| Modelo de dominio | Diagrama del vocabulario del negocio: entidades, atributos y relaciones. Sin claves ni métodos. |
| Entidad | Cosa del negocio que se necesita recordar y distinguir de otras del mismo tipo. |
| Atributo | Dato simple que describe a una entidad. No es una lista de entidades ni un dato calculable. |
| Relación | Línea con un verbo que conecta dos entidades. |
| Multiplicidad | 1, 0..1, 0..* o 1..*: cuántos de cada lado. Se lee en los dos sentidos. |
| ¿Atributo o entidad? | Si hay varios, se cuentan, se asignan o tienen datos propios, es entidad. |
| Entidad intermedia | Aparece cuando una relación muchos a muchos guarda datos propios (Membresía). |
| Fuera del dominio | Pantallas, botones, tablas y servidores: piezas del software, no del negocio. |
¿Sabías que...?
🗣️ Un lenguaje que entienda todo el equipo
Eric Evans, en su libro Domain-Driven Design (2003), propuso que el equipo y el negocio hablen con las mismas palabras, y que esas palabras aparezcan igual en el modelo y en el código. A eso lo llamó "lenguaje ubicuo".
🤖 La IA copia el vocabulario que le des
Si pegás tu modelo de dominio en el prompt, una IA usa esos nombres tal cual. Si no se lo das, inventa los suyos, y después hay que renombrar clases, tablas y variables en todo el proyecto.
🧭 Lo que viene en la próxima guía
Ya sabemos qué cosas maneja el sistema. El siguiente paso es la arquitectura por capas: cómo organizar el código para que el modelo de dominio quede en el centro y no dependa de la pantalla ni de la base de datos.