Taller: identificar las reglas de negocio de tu proyecto

1. Objetivos de aprendizaje

Al terminar este taller tu equipo va a ser capaz de:

• Distinguir una regla de negocio de una validación de formato y de un caso de “el id no existe”.
• Encontrar en el enunciado las reglas sobre los atributos de una entidad.
• Encontrar las reglas sobre las asociaciones entre entidades.
• Registrar cada regla en la wiki con su entidad, su condición y la excepción que se lanza (404 o 400).

Este taller no escribe código. Produce la tabla de reglas que vas a necesitar al escribir el Service, y que el Paso 1 del Release 7 pide como primer paso.

Antes de empezar, ten a mano:

• El enunciado del proyecto.
• El diagrama de clases consolidado y la tabla de asociaciones del Release 6.
• La teoría de Lógica de negocio, que ya muestra seis reglas resueltas y el patrón común de todas.

Las reglas salen del enunciado

Una regla de negocio se encuentra en el enunciado, no se inventa. Este paso no se delega a la IA: es justamente la parte que decide qué hace tu aplicación. Los ejemplos de este taller usan artistas, álbumes y canciones, y sus reglas son ilustrativas: las de tu proyecto son las que diga tu enunciado.

---

2. Qué es una regla de negocio (y qué no)

Una regla de negocio es una condición que el sistema exige antes de guardar, modificar o borrar un dato, y que viene del dominio del problema, no de la tecnología. Antes de registrar una candidata, hazle estas preguntas:

Pregunta	Si la respuesta es sí…
¿El enunciado la exige, aunque los datos estén bien escritos?	Es una regla de negocio.
¿Se falla por un id que no existe en la URL (GET /artistas/99)?	No es una regla: es un 404 (EntityNotFoundException) y ya lo cubre el Service.
¿Se falla porque el JSON viene mal formado o falta un campo de tipo incorrecto?	No es una regla de negocio: es la deserialización.
¿Cambiaría si el sistema usara otra base de datos u otro framework?	Si no cambia, es una regla de negocio.

Qué excepción lanza cada regla

Cada regla termina en una de las dos excepciones de la capa del Service:

Situación	Excepción	Código
El recurso que se busca por la URL no existe	EntityNotFoundException	404
La operación viola una regla de negocio, incluido un dato relacionado del cuerpo que no existe	IllegalOperationException	400

Así lo muestra la teoría: la regla de que la editorial debe existir al crear un libro lanza IllegalOperationException, porque el identificador viene en el cuerpo de la petición y no en la URL.

---

3. Cómo se registra: la tabla de la wiki

Todo el equipo trabaja sobre una sola tabla en la wiki del repositorio del grupo, con una fila por regla:

#	Entidad	Operación	Regla (en una frase)	Condición que la viola	Excepción
1	Artista	create	El nombre del artista es obligatorio	El nombre es null o está vacío	IllegalOperationException (400)

• Entidad: a qué entidad pertenece el Service donde se valida.
• Operación: create, update, delete (los que modifican datos). findAll y findById casi nunca llevan reglas.
• Regla: una frase en lenguaje del problema, sin código.
• Condición que la viola: lo que tiene que pasar para que falle. Esta columna es la que después se vuelve el if del Service.
• Excepción: EntityNotFoundException (404) o IllegalOperationException (400).

Si no puedes llenar una de las columnas, esa candidata todavía no es una regla.

---

4. Ronda 1: reglas sobre atributos básicos

Reglas que se pueden decidir mirando una sola entidad. Recorran, por cada entidad principal y cada atributo, estas cinco preguntas:

Tipo	Pregunta guía	Ejemplo resuelto
Obligatorio	¿Puede quedar vacío este atributo?	El título de un álbum es obligatorio
Rango	¿Hay un mínimo o un máximo que no se puede pasar?	Una canción no puede durar 0:00
Formato	¿El texto tiene que seguir un patrón?	La duración de una canción es m:ss, por ejemplo 4:06
Unicidad	¿Puede haber dos registros con el mismo valor? ¿Dentro de qué alcance?	No puede haber dos artistas con el mismo nombre
Coherencia entre atributos de una misma entidad	¿Dos atributos de la entidad se contradicen entre sí?	Un evento no puede terminar antes de empezar (fechaFin posterior a fechaInicio; es de otro dominio, porque una canción o un álbum solo tienen una fecha)

Algunas filas de la tabla de la wiki, con estos ejemplos:

#	Entidad	Operación	Regla	Condición que la viola	Excepción
1	Álbum	create	El título es obligatorio	El título es null o está vacío	IllegalOperationException (400)
2	Canción	create, update	La duración tiene formato m:ss	La duración no cumple el formato	IllegalOperationException (400)
3	Artista	create	No hay dos artistas con el mismo nombre	Ya existe un artista con ese nombre	IllegalOperationException (400)

Nota

Fíjate en la unicidad: la pregunta “¿dentro de qué alcance?” importa. El nombre de un departamento es único dentro de su compañía, no en toda la tabla (es la regla 5 de la teoría). Si el alcance está mal, la regla bloquea datos válidos o deja pasar duplicados.

Qué hacer en la ronda 1

1. Cada integrante toma una de las entidades de su módulo.
2. Recorre sus atributos con las cinco preguntas y busca en el enunciado cuáles aplican.
3. Agrega una fila por cada regla que encuentre, en la tabla compartida de la wiki.
4. Meta mínima: al menos una regla por cada entidad principal.

---

5. Ronda 2: reglas sobre asociaciones

Reglas que hay que decidir mirando dos o más entidades y la relación entre ellas. Usa la tabla de asociaciones del Release 6 y recorre cada una con estas cinco preguntas:

Tipo	Pregunta guía	Ejemplo resuelto
La entidad relacionada debe existir	Si se recibe el id de una entidad relacionada, ¿se comprueba que exista?	Al crear una canción hay que comprobar que el álbum que se indica existe
Relación que no puede repetirse	¿Se puede asociar dos veces el mismo par?	Un artista no puede asociarse dos veces al mismo álbum
Límite en una colección	¿Hay un máximo o un mínimo de elementos?	Un álbum no puede tener más de 30 canciones
Qué pasa al borrar	¿Se puede borrar una entidad que todavía tiene asociados?	No se puede borrar un álbum que todavía tiene canciones
Coherencia entre las entidades asociadas	¿Un atributo de una entidad depende de otro de la entidad relacionada?	La fecha de lanzamiento de una canción no puede ser anterior a la del álbum (parecido a la regla 3 de la teoría: la publicación de un libro debe ser posterior al nacimiento del autor)

Algunas filas más:

#	Entidad	Operación	Regla	Condición que la viola	Excepción
4	Canción	create	El álbum de la canción debe existir	El id del álbum no corresponde a ningún álbum	IllegalOperationException (400)
5	Álbum	delete	No se borra un álbum con canciones	El álbum todavía tiene canciones	IllegalOperationException (400)
6	Artista	asociar un álbum	No se asocia dos veces el mismo álbum	El artista ya tiene ese álbum	IllegalOperationException (400)

Por qué escribir la regla de borrar aunque la base la proteja

En el tutorial de @OneToMany viste que borrar un álbum con canciones ya falla: la llave foránea lo impide. Pero lo que le llega al cliente es un error interno de la base de datos (DataIntegrityViolationException), sin un mensaje que explique por qué. Si lo registras como regla, el Service puede comprobarlo antes y responder 400 con un mensaje claro.

Una distinción importante: 404 o 400 en las asociaciones

• Si el id viene en la URL (por ejemplo, POST /artistas/{id}/albumes/{albumId}) y no existe, es 404: el recurso que se está direccionando no existe. Es lo que pide el Release 7 para los endpoints de asociación.
• Si el id viene en el cuerpo de la petición (por ejemplo, el álbum al crear una canción) y no existe, es una regla violada: 400, como en el ejemplo de la editorial de la teoría.

Qué hacer en la ronda 2

1. Cada integrante toma las asociaciones en las que participa una de sus entidades.
2. Recorre cada asociación con las cinco preguntas.
3. Agrega las filas a la misma tabla de la wiki.
4. Meta mínima: cada asociación de la tabla del Release 6 tiene al menos una regla o una nota explícita de por qué no necesita ninguna.

---

6. Errores frecuentes

• Convertir una validación de formato del JSON en regla. Si el campo anio llega como texto cuando debería ser número, falla antes de llegar al Service. No es una regla de tu enunciado.
• Inventar reglas que el enunciado no dice. “Un artista no puede tener más de 10 álbumes” solo es una regla si tu enunciado lo exige. Cada regla extra es código y pruebas que mantener.
• Dejar la excepción sin asignar. Una fila sin 404 o 400 no se puede implementar ni probar.
• Usar 404 para una regla violada. El 404 es para el id que no existe en la URL. Una regla violada es 400.
• Repartir la validación entre el Controller y el Service. Todas las reglas van en el Service; el Controller solo traduce.
• Reglas escritas como código. La tabla se escribe en lenguaje del problema. El código viene después.

---

7. Cierre

Antes de dar el taller por terminado, el equipo revisa su tabla con esta lista:

• Cada entidad principal tiene al menos una regla.
• Cada asociación del Release 6 tiene al menos una regla, o una nota de por qué no la necesita.
• Todas las filas tienen operación, condición y excepción.
• Ninguna regla es una validación de formato del JSON.
• Cada regla se puede rastrear hasta una frase del enunciado.
• Todos los integrantes leyeron la tabla completa, no solo sus filas.

La tabla queda en la wiki del repositorio del grupo. Es la entrada del siguiente paso: escribir el <Entidad>Service y sus pruebas, donde cada fila de la tabla se vuelve una condición en create o update y una prueba del caso de error.