Cómo dibujar un diagrama de componentes

Antes de dibujar nada, escribe una lista. No de tus módulos ni de tus carpetas: de las partes del sistema que podrían cambiarse de forma plausible por otra implementación, compradas en vez de construidas, reescritas por otro equipo u operadas por alguien más.

Esa pregunta es todo el filtro. Una carpeta no es un componente y una clase tampoco; una cosa con una frontera que podrías entregar a un proveedor, sí. El sistema de informes de este artículo dio cuatro: un panel, un planificador que ejecuta informes por la noche, el propio servicio de informes y un adaptador que habla con el almacén de datos.

Coloca las piezas y resiste la tentación de conectarlas. Dibujar flechas ahora significa trazarlas entre componentes, y una línea del Dashboard directamente al servicio de informes solo dice «estos dos están implicados de algún modo», que es justamente la vaguedad que un diagrama de componentes existe para eliminar.

La disposición vale treinta segundos aquí: consumidores a un lado y proveedores al otro. Todos los diagramas de esta serie están dibujados de izquierda a derecha, con las dependencias fluyendo en un solo sentido, porque así el lector comprueba la dirección de un vistazo en vez de siguiendo cada línea.

Para cada caja, pregunta en qué puede apoyarse alguien de fuera, y nómbralo. Aquí IReports e IWarehouse: un contrato por capacidad, no uno por consumidor. Únelo con una realización: línea discontinua, triángulo hueco, apuntando a la interfaz.

En este paso ocurre el diseño de verdad, y es el paso que la gente se salta. Nombrar un contrato te obliga a decidir qué es público, y la discusión que sigue - «¿la exportación a CSV forma parte de IReports o no?» - es la discusión que conviene tener antes de que dos equipos la respondan de forma distinta en el código.

Ahora la segunda mitad, la que lleva la información: ¿qué contratos necesita cada componente? Dibuja una dependencia - línea discontinua, punta abierta - desde el componente hacia la interfaz que requiere. El resultado es el diagrama del principio de este artículo.

En cuanto esas flechas aterrizan se hacen visibles dos cosas. El panel y el planificador apuntan ambos a IReports, así que cambiarlo es ahora visiblemente un cambio para dos consumidores. Y el servicio de informes apunta a IWarehouse y no al adaptador, así que el adaptador es reemplazable sin que el servicio se entere, lo cual es o bien lo que pretendías o bien un descubrimiento que conviene hacer ahora.

Un diagrama de componentes está terminado cuando las sobrevive. Llevan un minuto y cada una ha cazado un problema real más veces de las que ha pasado limpia.

1. Tapa una caja con la mano. Lo que queda - las interfaces que estaban unidas a ella - es la especificación de su reemplazo. Si ese reemplazo necesitara saber algo que no está en pantalla, la frontera está en el sitio equivocado.
2. Sigue las flechas buscando un ciclo. Dos componentes que se requieren mutuamente no se pueden desplegar, probar ni reemplazar de forma independiente. Mira el último de los ejemplos resueltos para ver cómo se ve y cómo se rompe.
3. Comprueba que cada componente tiene al menos una interfaz. Una caja sin nada unido o no es un componente o no es relevante para este diagrama.
4. Lee los nombres de las interfaces en voz alta. Si alguno está nombrado por su proveedor actual en vez de por su capacidad - IMainframeBilling en lugar de IBilling - el contrato lleva al proveedor incrustado, y el cambio que el diagrama promete no será tan limpio como parece.

La columna derecha no es pedantería sobre tipos de diagrama. Cada elemento agranda la imagen sin responder la pregunta para la que se dibujó el diagrama, y cada uno le da una segunda razón para quedar obsoleto: un diagrama de componentes sobrevive intacto a un cambio de plataforma, y el mismo dibujo con dos regiones de AWS encima no.

Con el dibujo hecho, la referencia de cada marca que aparece en él está en símbolos del diagrama de componentes, y el argumento más amplio sobre cuándo merece la pena este tipo de diagrama está en la guía del diagrama de componentes.