31. Evolución del modelo: cambios de reglas, nuevos conceptos y refactorización

31.1 Introducción

Un modelo de dominio no queda terminado para siempre. Evoluciona cuando el equipo aprende más, cuando cambian reglas del negocio, cuando aparecen nuevos conceptos, cuando se descubren ambigüedades o cuando el sistema empieza a cubrir procesos más complejos.

La evolución del modelo debe ser esperada, no vista como un fracaso. Un modelo inicial suele ser una hipótesis razonable. A medida que se valida con escenarios y se usa en decisiones de diseño, aparecen mejoras necesarias.

31.2 Imagen conceptual de evolución del modelo

31.3 Por qué evoluciona un modelo

Un modelo evoluciona porque el dominio no siempre se comprende completamente desde el inicio. Algunas reglas aparecen tarde, algunos términos cambian, ciertos procesos se vuelven más complejos y nuevas áreas del negocio se incorporan al sistema.

Lo importante es que el cambio sea consciente. No debe acumularse como parches desordenados, sino incorporarse manteniendo coherencia.

31.4 Cambios de reglas de negocio

Las reglas pueden cambiar por decisiones internas, regulación, estrategia comercial, experiencia operativa o nuevas restricciones. Por ejemplo, una política de cancelación puede pasar de 24 a 48 horas de anticipación. Una agenda puede permitir sobreturnos solo en ciertos días. Una prestación puede requerir autorización previa.

Cuando cambia una regla, debemos revisar qué conceptos, estados, eventos, invariantes, casos de uso y pruebas se ven afectados.

31.5 Aparición de nuevos conceptos

A veces el modelo necesita incorporar conceptos que antes no existían o no habían sido descubiertos. En un sistema de turnos pueden aparecer Sobreturno, Lista de espera, Bloqueo de agenda, Confirmación automática o Motivo de ausencia.

Un nuevo concepto debe analizarse con el mismo rigor que los iniciales: significado, relaciones, atributos, reglas, estados y eventos. No conviene agregarlo solo como campo o comentario si tiene comportamiento propio.

31.6 Cambio de significado de un concepto

También puede ocurrir que un concepto ya existente cambie de significado. Tal vez "Reserva" inicialmente era sinónimo de Turno, pero luego se descubre que una reserva puede estar pendiente antes de convertirse en turno confirmado. En ese caso, el modelo debe separar ambos conceptos o redefinirlos.

Estos cambios son delicados porque pueden afectar lenguaje ubicuo, documentación, pruebas y código. Por eso conviene registrar la decisión y actualizar artefactos relacionados.

31.7 Refactorización del modelo

Refactorizar el modelo significa mejorar su estructura sin cambiar necesariamente el comportamiento observable del negocio. Puede implicar renombrar conceptos, separar una entidad en dos, convertir un atributo en objeto de valor, mover una regla a un agregado o extraer un servicio de dominio.

La refactorización busca que el modelo exprese mejor el conocimiento actual. No es solo limpieza estética; reduce ambigüedad y facilita evolución futura.

31.8 Ejemplos de refactorización

Algunos ejemplos frecuentes son:

• Renombrar "Usuario" a "Paciente" cuando el concepto real no es cualquier usuario del sistema.
• Separar Turno y Reserva si tienen ciclos de vida distintos.
• Convertir monto y moneda en objeto de valor Dinero.
• Extraer Política de cancelación cuando la regla deja de pertenecer solo a Turno.
• Crear Lista de espera cuando los escenarios muestran demanda sin disponibilidad.
• Separar contexto de Turnos y contexto de Facturación cuando el modelo se vuelve ambiguo.

31.9 Evolución y trazabilidad

La trazabilidad ayuda a evolucionar el modelo con menos riesgo. Si sabemos qué requerimientos, casos de uso y pruebas se relacionan con una regla, podemos estimar el impacto de cambiarla.

Por ejemplo, si cambia la política de cancelación, la trazabilidad nos ayuda a encontrar escenarios, reglas, diagramas de estados y pruebas que deben actualizarse.

31.10 Evolución y lenguaje ubicuo

Cuando el modelo cambia, el lenguaje ubicuo también puede cambiar. Un nuevo concepto debe incorporarse al vocabulario. Un término ambiguo puede reemplazarse. Un sinónimo puede eliminarse.

Si el lenguaje no se actualiza, el equipo seguirá usando palabras antiguas para ideas nuevas. Eso genera inconsistencias entre conversaciones, documentos, diagramas y código.

31.11 Versiones de reglas

Algunas reglas cambian, pero el sistema debe conservar historia. Por ejemplo, una cancelación realizada en enero pudo regirse por una política de 24 horas, mientras que desde marzo se exige 48 horas. En esos casos, no alcanza con reemplazar la regla sin pensar en datos históricos.

El modelo puede necesitar representar vigencia de políticas, versiones de reglas o eventos que registren bajo qué condición se tomó una decisión.

31.12 Evolución de diagramas

Los diagramas deben acompañar al modelo. Si un diagrama deja de representar la realidad del dominio, se vuelve peligroso. Puede confundir a nuevos integrantes o justificar decisiones equivocadas.

No todos los diagramas necesitan actualizarse con cada pequeño cambio, pero los diagramas que se usan para comunicar reglas importantes deben mantenerse vigentes.

31.13 Tabla de cambios frecuentes

La siguiente tabla muestra cambios típicos y posibles acciones:

31.14 Gestión del cambio

Cambiar el modelo requiere comunicación. Los expertos del negocio deben validar nuevas reglas. El equipo técnico debe entender impacto en diseño y pruebas. La documentación debe actualizarse si se usa como referencia.

Una buena práctica es registrar decisiones importantes: qué cambió, por qué cambió, qué alternativas se descartaron y qué artefactos fueron afectados.

31.15 Preguntas para evolucionar el modelo

Estas preguntas ayudan a decidir cómo adaptar el modelo:

• ¿El cambio es una nueva regla, un nuevo concepto o un cambio de significado?
• ¿Qué escenarios actuales deja de explicar el modelo?
• ¿Qué conceptos, asociaciones, estados o eventos se ven afectados?
• ¿El cambio pertenece al mismo contexto o requiere separar contextos?
• ¿Hay datos históricos que dependan de reglas anteriores?
• ¿Qué pruebas y documentos deben actualizarse?
• ¿El cambio mejora la claridad del lenguaje ubicuo?

31.16 Errores frecuentes

Al evolucionar modelos, suelen aparecer estos errores:

• Agregar campos para resolver nuevos conceptos sin analizarlos.
• Modificar reglas sin revisar escenarios y pruebas afectados.
• No actualizar lenguaje ubicuo ni diagramas relevantes.
• Conservar nombres antiguos para significados nuevos.
• Mezclar contextos para evitar una separación necesaria.
• No considerar datos históricos cuando cambian reglas.
• Evitar refactorizar por miedo, acumulando confusión en el modelo.

31.17 Qué debes recordar de este tema

• El modelo de dominio evoluciona cuando cambia el negocio o mejora el conocimiento.
• Los cambios pueden afectar reglas, conceptos, estados, eventos y contextos.
• Refactorizar el modelo mejora su expresión sin cambiar necesariamente el comportamiento.
• La trazabilidad ayuda a analizar impacto.
• El lenguaje ubicuo debe actualizarse junto con el modelo.
• Las reglas con vigencia histórica requieren especial cuidado.
• Un modelo que no evoluciona termina alejándose del negocio real.

31.18 Conclusión

La evolución del modelo de dominio es parte natural del desarrollo de software. A medida que el equipo aprende y el negocio cambia, el modelo debe adaptarse. Lo importante es que esa evolución sea consciente, trazable y validada con expertos.

En el próximo tema veremos errores frecuentes al modelar el dominio y cómo evitarlos.