Cuánto de un sistema modelar

Antes de dibujar cualquier vista, termina esta frase: «Esta vista existe para que [persona] pueda decidir [cosa].» Si no puedes rellenar los dos huecos, no la dibujes.

La prueba funciona porque es refutable, que es justo lo que no es ningún otro consejo sobre el tema. «Modela las partes importantes» no puede perder una discusión; «este diagrama de clases existe para que el equipo de plataforma pueda decidir si el cálculo del impuesto pertenece a facturación» o es cierto o no lo es, y a la persona nombrada se le puede preguntar.

Aplicada con honestidad elimina la mayor parte de lo que se modela. Un diagrama del sistema actual dibujado porque alguien debería documentarlo no informa de nada. Una vista que muestra todos los servicios del parque no informa de nada, porque ninguna decisión trata sobre todos a la vez. Lo que sobrevive es un número pequeño de vistas, cada una apuntada a una discusión que alguien está teniendo.

Se convierte en una segunda implementación. Cada clase, cada campo, cada llamada: un modelo a esa fidelidad es una copia del código escrita en una notación, y la copia siempre es la que está mal. Este es el fallo que le dio al modelado su reputación, y viene enteramente de no preguntar para qué sirve el modelo.

Se convierte en una foto del organigrama. Los modelos sin alcance derivan hacia mostrar el sistema de cada equipo con el mismo peso, porque es políticamente el arreglo más fácil. El resultado es un diagrama en el que los dos componentes que de verdad interactúan son del mismo tamaño que veinte que no, y nadie encuentra la pregunta.

Se vuelve inmantenible de la forma más ordinaria. Sin drama: simplemente conteniendo más detalle del que el equipo tiene ganas de actualizar, de modo que unos cuantos elementos caducan, luego unos cuantos más, y en dos trimestres el modelo es algo que la gente contrasta con el código en lugar de creerlo.

Un modelo, varias vistas pequeñas. El alcance es una propiedad de la vista y no del modelo: el modelo puede contener todo lo que alguien haya introducido, y cada vista muestra el puñado de elementos que necesita una decisión. Para eso está el mecanismo de puntos de vista de ArchiMate, y vale igual de bien para UML.

Modela un nivel por debajo de la decisión, no dos. Si la discusión es sobre qué servicio es dueño de una responsabilidad, modela los servicios y sus dependencias. No modeles las clases que hay dentro; ese detalle no puede cambiar la respuesta, y es justo el detalle que se pudrirá.

Borra las vistas que ya cumplieron su función. Una vista dibujada para una migración que ya ocurrió está terminada, y conservarla significa que un lector futuro encontrará un diagrama seguro de sí mismo de una arquitectura que ya no existe. Borrar documentación se siente mal y suele ser lo correcto.

Lo siguiente en esta serie: convenciones de nombres y después mantener un modelo al día.