13. Generalización y especialización: jerarquías útiles y jerarquías innecesarias
13.1 Introducción
La generalización y la especialización permiten organizar conceptos del dominio en jerarquías. Un concepto general reúne características comunes, mientras que los conceptos especializados agregan diferencias relevantes. Por ejemplo, Persona puede generalizar a Paciente y Profesional si ambos comparten datos básicos, pero cumplen reglas y roles diferentes.
Las jerarquías pueden aclarar el modelo cuando reflejan diferencias reales del negocio. También pueden complicarlo cuando se usan por costumbre, por parecido superficial o por trasladar prematuramente ideas de programación al análisis conceptual.
13.2 Imagen conceptual de jerarquías
13.3 Qué es generalizar
Generalizar significa identificar un concepto más amplio que agrupa conceptos más específicos. Por ejemplo, si Paciente y Profesional comparten nombre, documento y datos de contacto, podríamos pensar en un concepto general Persona.
Pero generalizar no consiste solo en encontrar atributos repetidos. La generalización debe tener sentido para el dominio. Si el negocio no habla de Persona o no necesita reglas comunes para personas, quizá esa abstracción no aporte claridad.
13.4 Qué es especializar
Especializar significa definir conceptos más concretos a partir de uno general. Cada especialización hereda el significado común y agrega reglas, relaciones o comportamientos propios. Por ejemplo, Profesional puede tener matrícula, especialidades y agenda; Paciente puede tener historia clínica, cobertura e historial de turnos.
Una especialización debe responder a diferencias importantes. Si los conceptos especializados no tienen reglas ni relaciones distintas, tal vez no haga falta crear una jerarquía.
13.5 Jerarquías útiles
Una jerarquía suele ser útil cuando:
- El dominio reconoce claramente un concepto general y sus variantes.
- Las variantes comparten reglas o atributos significativos.
- Cada especialización tiene reglas, relaciones o restricciones propias.
- La jerarquía ayuda a explicar el modelo a expertos del negocio.
- El vocabulario de negocio usa expresiones del tipo "es un tipo de".
- La clasificación es relativamente estable.
13.6 Jerarquías innecesarias
Una jerarquía puede ser innecesaria cuando solo se crea para ordenar visualmente conceptos, evitar repetición mínima de atributos o imitar una estructura técnica. Si la jerarquía no ayuda a expresar reglas ni a conversar con expertos, probablemente agrega complejidad.
Por ejemplo, crear PacienteConEmail y PacienteSinEmail como subtipos sería exagerado si la diferencia solo es la presencia opcional de un dato. En ese caso, un atributo opcional o una regla de contacto puede ser suficiente.
13.7 La prueba "es un tipo de"
Una heurística simple consiste en probar si la frase "es un tipo de" tiene sentido en el dominio. Un Profesional es un tipo de Persona puede sonar razonable. Un Turno cancelado es un tipo de Turno puede parecer razonable, pero quizás en realidad "cancelado" sea un estado, no una especialización.
La prueba ayuda, pero no alcanza. Además de sonar bien, la jerarquía debe aportar reglas o diferencias conceptuales claras.
13.8 Tipos frente a estados
Un error frecuente es confundir tipos con estados. Un tipo suele representar una clasificación más estable. Un estado representa una situación transitoria dentro del ciclo de vida de una entidad.
Por ejemplo, Turno presencial y Turno virtual podrían ser tipos de turno si tienen reglas y datos diferentes. En cambio, Turno reservado, Turno cancelado y Turno atendido probablemente sean estados, porque un mismo turno puede pasar por esas situaciones durante su vida.
13.9 Tipos frente a roles
También es común confundir tipos con roles. Un rol es una función que una persona o entidad cumple en un contexto determinado. Una misma persona puede ser Paciente, Profesional, Responsable de pago o Usuario administrativo, según el dominio.
Si una entidad puede cumplir varios papeles al mismo tiempo o cambiar de papel según el contexto, modelar cada rol como subtipo puede ser limitante. A veces conviene modelar Persona y asociarla con roles, permisos o perfiles.
13.10 Tipos frente a categorías configurables
Algunas clasificaciones no deberían convertirse en jerarquías porque son configurables por el negocio. Por ejemplo, tipos de especialidad, categorías de producto, motivos de cancelación o niveles de prioridad pueden cambiar sin alterar la estructura conceptual principal.
Si cada nueva categoría exige modificar el modelo, quizás la jerarquía está demasiado rígida. En esos casos puede convenir modelar Categoría, Tipo o Motivo como conceptos configurables.
13.11 Ejemplo: Persona, Paciente y Profesional
En un sistema de turnos, Persona puede generalizar información común como nombre, documento y datos de contacto. Paciente puede especializar Persona con historia clínica, cobertura y reglas de reserva. Profesional puede especializar Persona con matrícula, especialidades y agenda.
Esta jerarquía puede ser útil si el dominio realmente trata a ambos como personas y existen reglas comunes. Pero si Paciente y Profesional se gestionan de forma completamente separada, o si una misma persona puede ser ambas cosas, quizá convenga modelar roles en lugar de herencia conceptual rígida.
13.12 Ejemplo: Turnos presenciales y virtuales
Turno presencial y Turno virtual podrían ser especializaciones si tienen reglas diferentes. Un turno presencial puede requerir consultorio o sede. Un turno virtual puede requerir enlace de videollamada, plataforma y reglas de conexión.
Si la única diferencia es un atributo "modalidad", quizá no conviene crear subtipos. La decisión depende de si las reglas del negocio son realmente distintas y significativas.
13.13 Herencia conceptual no es herencia de programación
En modelado de dominio, una jerarquía expresa una relación conceptual. No obliga a implementar herencia de clases en el código. Durante el diseño técnico, el equipo puede representar esa diferencia con herencia, composición, estrategias, tipos enumerados, tablas separadas u otros mecanismos.
Confundir herencia conceptual con herencia de programación puede llevar a modelos rígidos. Primero debemos entender la clasificación del negocio; luego se decide cómo implementarla.
13.14 Tabla de decisiones
La siguiente tabla muestra situaciones frecuentes:
| Situación | Posible enfoque | Motivo |
|---|---|---|
| Paciente y Profesional comparten datos, pero tienen reglas propias. | Generalización Persona, si el dominio la reconoce. | Existe parte común y diferencias relevantes. |
| Turno reservado, cancelado y atendido. | Estados de Turno. | Un turno puede cambiar entre esas situaciones. |
| Usuario administrador y usuario operador. | Roles o permisos. | Puede depender del contexto y cambiar con el tiempo. |
| Motivos de cancelación configurables. | Catálogo o tipo configurable. | El negocio puede agregar motivos sin cambiar el modelo principal. |
| Turno presencial y virtual con reglas distintas. | Especialización o modalidad con reglas. | Depende de la cantidad y profundidad de diferencias. |
13.15 Preguntas para validar una jerarquía
Antes de crear una jerarquía, conviene preguntar:
- ¿El negocio reconoce el concepto general?
- ¿Cada especialización tiene reglas o relaciones propias?
- ¿La frase "es un tipo de" tiene sentido para expertos del dominio?
- ¿La clasificación es estable o cambia con frecuencia?
- ¿Una instancia puede pertenecer a varias categorías al mismo tiempo?
- ¿La diferencia es realmente un tipo, un estado, un rol o una configuración?
- ¿La jerarquía simplifica el modelo o lo vuelve más difícil de entender?
13.16 Errores frecuentes
Al modelar generalización y especialización, suelen aparecer estos errores:
- Crear jerarquías solo para evitar repetir atributos.
- Confundir estados con subtipos.
- Confundir roles con subtipos rígidos.
- Convertir categorías configurables en clases especializadas.
- Usar herencia conceptual pensando directamente en herencia de programación.
- Crear niveles de jerarquía que los expertos del negocio no reconocen.
- No revisar si la jerarquía seguirá siendo válida cuando cambien las reglas.
13.17 Qué debes recordar de este tema
- La generalización agrupa conceptos específicos bajo un concepto más general.
- La especialización agrega diferencias relevantes dentro del dominio.
- Una jerarquía es útil cuando expresa reglas y significados reales del negocio.
- No todo parecido entre conceptos justifica una jerarquía.
- Estados, roles y categorías configurables no siempre deben modelarse como subtipos.
- La herencia conceptual no obliga a usar herencia de programación.
- Las jerarquías deben validarse con expertos y ejemplos concretos.
13.18 Conclusión
La generalización y la especialización son herramientas útiles cuando ayudan a expresar diferencias reales del dominio. Pero una jerarquía mal elegida puede volver el modelo rígido, difícil de mantener y alejado del lenguaje del negocio. Antes de crear subtipos, conviene revisar si la diferencia corresponde a un tipo, un estado, un rol o una configuración.
En el próximo tema estudiaremos las reglas de negocio, incluyendo condiciones, restricciones, cálculos y decisiones que el modelo debe hacer visibles.