33. Checklist para revisar la calidad de un modelo de dominio

33.1 Introducción

Después de construir un modelo de dominio, conviene revisarlo con una lista de criterios. Un checklist ayuda a detectar omisiones, ambigüedades, mezclas con tecnología, reglas ocultas y problemas de validación.

Este tema propone una guía práctica. No debe usarse como una evaluación burocrática, sino como apoyo para conversaciones de mejora con el equipo y con expertos del negocio.

33.2 Imagen conceptual de revisión

33.3 Criterio 1: propósito claro

Antes de revisar detalles, hay que confirmar para qué existe el modelo. Un modelo puede servir para comprender un proceso, validar reglas, orientar diseño, explicar un contexto o documentar decisiones.

• ¿El objetivo del modelo está claro?
• ¿El nivel de detalle es adecuado para ese objetivo?
• ¿El modelo responde una pregunta real del proyecto?

33.4 Criterio 2: lenguaje ubicuo

El modelo debe usar vocabulario del negocio. Los expertos deben reconocer los términos y poder discutirlos sin traducir constantemente desde lenguaje técnico.

• ¿Los nombres pertenecen al lenguaje del dominio?
• ¿Hay términos ambiguos sin definición?
• ¿Existen sinónimos innecesarios?
• ¿El glosario está actualizado?

33.5 Criterio 3: conceptos relevantes

El modelo debe contener conceptos que aportan significado. No debe incluir todo lo que aparece en documentos o pantallas sin analizarlo.

• ¿Cada concepto tiene significado claro?
• ¿Hay conceptos técnicos que deberían eliminarse?
• ¿Faltan conceptos mencionados por los expertos?
• ¿Se distingue entidad, objeto de valor, estado, evento y rol?

33.6 Criterio 4: atributos con sentido

Los atributos deben ser relevantes para el dominio. No conviene trasladar todos los campos de una pantalla o tabla al modelo conceptual.

• ¿Cada atributo tiene significado de negocio?
• ¿Hay datos derivados o calculados identificados como tales?
• ¿Hay atributos que deberían ser objetos de valor?
• ¿Se reconocen datos sensibles o históricos?

33.7 Criterio 5: asociaciones y multiplicidades

Las asociaciones deben tener significado claro. Las multiplicidades deben expresar reglas reales, no supuestos.

• ¿Cada asociación puede leerse como una frase del dominio?
• ¿Las multiplicidades fueron validadas con ejemplos?
• ¿Hay relaciones redundantes o derivadas sin aclarar?
• ¿Los roles de las asociaciones son comprensibles?

33.8 Criterio 6: reglas de negocio visibles

Un modelo de dominio de calidad no oculta reglas importantes. Debe mostrar condiciones, restricciones, cálculos, decisiones e invariantes.

• ¿Las reglas importantes están documentadas o anotadas?
• ¿Se distinguen reglas estables y políticas cambiantes?
• ¿Los invariantes están identificados?
• ¿Las reglas fueron validadas con contraejemplos?

33.9 Criterio 7: estados y eventos

Si hay objetos con ciclo de vida, sus estados y transiciones deben estar claros. Los eventos importantes deben nombrarse en pasado y con lenguaje del dominio.

• ¿Los estados afectan reglas o acciones permitidas?
• ¿Las transiciones válidas están identificadas?
• ¿Los eventos importantes están nombrados en pasado?
• ¿Se diferencian comandos, consultas y eventos?

33.10 Criterio 8: agregados y límites de consistencia

Cuando el modelo incluye agregados, debe quedar claro qué reglas internas protegen y cuál es la raíz de agregado.

• ¿Cada agregado tiene una raíz clara?
• ¿Se conocen los invariantes que protege?
• ¿El agregado es tan pequeño como sea posible?
• ¿Se evita modificar entidades internas desde afuera?

33.11 Criterio 9: contextos delimitados

Si el dominio es grande, conviene revisar si existen significados distintos según áreas del negocio.

• ¿Hay términos con significados diferentes en distintas áreas?
• ¿Los contextos están delimitados por significado y no solo por tecnología?
• ¿Se conoce qué expertos validan cada contexto?
• ¿Las relaciones entre contextos están claras?

33.12 Criterio 10: validación con escenarios

El modelo debe haber sido probado con situaciones concretas. Los escenarios muestran si los conceptos y reglas funcionan juntos.

• ¿Se validaron escenarios normales?
• ¿Se revisaron flujos alternativos y excepciones?
• ¿Se usaron contraejemplos?
• ¿Los expertos del dominio confirmaron el modelo?

33.13 Criterio 11: trazabilidad

La trazabilidad permite entender origen e impacto de conceptos y reglas.

• ¿Sabemos de dónde surge cada regla importante?
• ¿Los conceptos clave se relacionan con requerimientos o casos de uso?
• ¿Las pruebas cubren reglas críticas?
• ¿Podemos analizar impacto si cambia una política?

33.14 Criterio 12: claridad visual

Si el modelo se representa con diagramas, deben ser legibles. Un diagrama muy grande o desordenado puede ocultar más de lo que explica.

• ¿El diagrama tiene tamaño razonable?
• ¿Los nombres se leen con claridad?
• ¿Las relaciones importantes están destacadas?
• ¿Se evita mezclar demasiados objetivos en un solo diagrama?

33.15 Tabla resumida de checklist

33.16 Cómo usar el checklist

El checklist puede usarse en una revisión de equipo. No hace falta responder todo con formalidad excesiva. Lo importante es detectar dudas y convertirlas en acciones: validar una regla, renombrar un concepto, dividir un diagrama, agregar escenarios o separar contextos.

También puede usarse antes de entregar documentación, antes de pasar a diseño técnico o después de descubrir cambios importantes en el negocio.

33.17 Errores al usar checklists

Incluso un checklist puede usarse mal. Algunos errores son:

• Responder mecánicamente sin discutir el modelo.
• Usarlo como control burocrático en lugar de herramienta de aprendizaje.
• Exigir el mismo nivel de detalle para todos los proyectos.
• No convertir problemas detectados en acciones concretas.
• No volver a revisar el modelo cuando evoluciona el dominio.

33.18 Qué debes recordar de este tema

• Un checklist ayuda a revisar calidad y detectar omisiones.
• Debe cubrir lenguaje, conceptos, atributos, asociaciones, reglas, estados y eventos.
• También debe revisar agregados, contextos, validación y trazabilidad.
• La calidad del modelo depende de su utilidad para comprender el dominio.
• El checklist debe generar conversaciones y acciones, no burocracia.
• Debe adaptarse al tamaño, riesgo y contexto del proyecto.
• Un buen modelo es claro, validado, trazable y capaz de evolucionar.

33.19 Conclusión

Revisar la calidad de un modelo de dominio requiere mirar más que la apariencia del diagrama. Hay que evaluar vocabulario, significado, reglas, consistencia, validación, trazabilidad y capacidad de evolución. Un checklist bien usado ayuda a encontrar puntos débiles y mejorar el modelo antes de que sus errores se propaguen.

En el próximo tema cerraremos el curso con un caso práctico de modelado de dominio de un sistema de gestión de turnos.