32. Errores frecuentes al modelar el dominio y cómo evitarlos

32.1 Introducción

Modelar el dominio exige comprender el negocio, elegir buenos nombres, representar reglas y validar con ejemplos. Por eso es normal cometer errores, especialmente cuando el equipo empieza a mezclar análisis con diseño técnico o cuando trabaja con información incompleta.

Este tema reúne errores frecuentes y formas prácticas de evitarlos. La intención no es memorizar una lista, sino aprender a detectar señales de un modelo débil antes de que se transforme en código, documentación o decisiones difíciles de cambiar.

32.2 Imagen conceptual de errores y correcciones

32.3 Confundir dominio con tecnología

Uno de los errores más comunes es modelar tablas, pantallas, controladores, DTO o endpoints en lugar de conceptos del negocio. Esto produce modelos que el equipo técnico entiende parcialmente, pero que los expertos del dominio no pueden validar con facilidad.

Para evitarlo, conviene preguntar si cada elemento pertenece al negocio o a la solución técnica. Paciente, Turno y Agenda son conceptos del dominio. TablaTurnos, PantallaReserva y TurnoDTO pertenecen a la implementación.

32.4 Usar nombres ambiguos

Un nombre ambiguo genera interpretaciones distintas. Palabras como usuario, cliente, solicitud, orden, reserva o estado pueden significar cosas diferentes según el contexto.

Para evitar este error, hay que construir lenguaje ubicuo con expertos del negocio, registrar definiciones y usar ejemplos. Si una palabra tiene varios significados, quizá haga falta separar conceptos o contextos delimitados.

32.5 Convertir todo sustantivo en entidad

No todo sustantivo encontrado en entrevistas o documentos debe convertirse en entidad. Algunos términos son atributos, objetos de valor, estados, eventos, documentos, roles o detalles técnicos.

Para evitar entidades innecesarias, conviene preguntar si el concepto tiene identidad, ciclo de vida, reglas propias y relaciones significativas. Si solo describe una característica simple, quizá sea atributo. Si se compara por sus valores, quizá sea objeto de valor.

32.6 Ignorar reglas de negocio

Un modelo que solo muestra conceptos y relaciones puede ser insuficiente. Las reglas explican qué está permitido, qué está prohibido, qué se calcula y qué decisiones se toman.

Para evitar este error, hay que buscar frases como "no se puede", "solo si", "al menos", "como máximo", "excepto cuando" o "depende de". También conviene agregar notas, restricciones o tablas de reglas cuando el diagrama no alcanza.

32.7 No validar con escenarios

Un modelo puede parecer correcto en abstracto y fallar con casos reales. Si no se valida con escenarios, ejemplos y contraejemplos, pueden quedar ocultas reglas importantes.

Para evitarlo, hay que probar el modelo con casos normales, alternativos, excepcionales y casos límite. Los expertos del negocio deben participar en esa validación.

32.8 Mezclar niveles de abstracción

Otro error frecuente es mezclar conceptos del negocio con clases técnicas, tablas, pantallas y detalles de infraestructura en el mismo modelo. Esto vuelve difícil entender qué parte representa análisis y qué parte representa diseño.

Para evitarlo, conviene separar modelos conceptuales, modelos de diseño y modelos técnicos. Pueden relacionarse, pero no deben mezclarse sin criterio.

32.9 Crear modelos demasiado grandes

Un diagrama enorme suele ser difícil de leer y validar. Aunque contenga mucha información, puede no ayudar a nadie a tomar decisiones.

Para evitarlo, conviene dividir el modelo por contextos, áreas o preguntas. Un diagrama debe mostrar lo necesario para comunicar una idea, no todo el universo del sistema.

32.10 Usar UML como fin en sí mismo

UML es una herramienta de comunicación, no el objetivo final. Un diagrama con símbolos correctos puede representar mal el dominio. También puede ser demasiado formal para una conversación inicial.

Para evitar este error, hay que elegir el diagrama según la pregunta: clases para estructura conceptual, estados para ciclo de vida, actividades para procesos y objetos para ejemplos concretos.

32.11 Confundir estados, tipos y roles

Turno cancelado suele ser un estado, no un subtipo. Usuario administrador puede ser un rol, no una clase especializada. Categoría de producto puede ser una clasificación configurable, no una jerarquía rígida.

Para evitar este error, hay que preguntar si la característica cambia durante el ciclo de vida, si puede coexistir con otras, si depende del contexto o si es una categoría que el negocio puede configurar.

32.12 No distinguir entidades y objetos de valor

Las entidades se reconocen por identidad. Los objetos de valor se reconocen por sus atributos. Confundirlos puede producir modelos con identidades innecesarias o valores tratados como datos sueltos.

Para evitarlo, hay que preguntar si el negocio necesita seguir la continuidad del objeto en el tiempo. Si no tiene identidad propia y se compara por sus atributos, probablemente sea objeto de valor.

32.13 Ocultar invariantes

Los invariantes son propiedades que siempre deben cumplirse. Si no se identifican, el sistema puede permitir estados inválidos. Por ejemplo, franjas superpuestas, pedidos confirmados sin ítems o turnos reservados sin paciente.

Para evitarlo, conviene preguntar qué condiciones nunca deberían romperse y qué concepto debe protegerlas.

32.14 Tabla de errores y prevención

La siguiente tabla resume errores habituales:

32.15 Preguntas de revisión

Estas preguntas ayudan a detectar errores temprano:

• ¿El modelo usa lenguaje del negocio o lenguaje técnico?
• ¿Cada concepto tiene significado claro?
• ¿Las reglas importantes están visibles?
• ¿El modelo fue validado con ejemplos y contraejemplos?
• ¿Hay elementos que pertenecen a otro contexto?
• ¿Los diagramas son comprensibles para sus destinatarios?
• ¿Sabemos qué invariantes debe proteger el modelo?

32.16 Cómo corregir un modelo débil

Cuando un modelo tiene problemas, conviene corregirlo en pasos. Primero identificar términos ambiguos. Luego separar elementos técnicos del dominio. Después revisar reglas, multiplicidades y estados con escenarios concretos. Finalmente, actualizar diagramas y trazabilidad.

Corregir un modelo no significa rehacer todo. Muchas veces alcanza con renombrar conceptos, agregar reglas, dividir un contexto o reemplazar una jerarquía innecesaria por estados o roles.

32.17 Qué debes recordar de este tema

• Muchos errores surgen por mezclar dominio con solución técnica.
• El lenguaje ubicuo reduce ambigüedad.
• No todo sustantivo es entidad.
• Las reglas de negocio deben quedar visibles.
• Los escenarios y contraejemplos son esenciales para validar.
• Los diagramas deben responder preguntas concretas.
• Un modelo debe evolucionar cuando se descubren errores o nuevos significados.

32.18 Conclusión

Los errores de modelado son inevitables, pero pueden detectarse temprano si el equipo trabaja con lenguaje claro, reglas visibles, escenarios concretos y validación con expertos. Un buen modelador no busca hacer diagramas perfectos desde el primer intento; busca aprender del dominio y ajustar el modelo con criterio.

En el próximo tema construiremos un checklist para revisar la calidad de un modelo de dominio.