Todo diagrama de microservicios empieza limpio y acaba siendo una maraña. Es casi una ley. Dibujas los servicios, dibujas las llamadas entre ellos y, antes de llegar a veinte cajas, es una red ilegible de flechas cruzadas que no te dice nada salvo "es complicado". El problema no es la arquitectura. Es que el diagrama intenta mostrar todas las conexiones a la vez, cuando lo que el lector necesita es la forma: los límites y la manera en que los servicios se comunican.
La salida es dejar de dibujar "cada servicio llama a cada servicio" y dibujar a propósito dos cosas: los límites que agrupan los servicios y el estilo de comunicación de cada arista. Hazlo y hasta un sistema grande sigue siendo legible.
Agrupa por límite, no en cuadrícula
La mayor mejora que puedes hacer es dejar de colocar los servicios en una cuadrícula ordenada y empezar a agruparlos según el límite al que pertenecen. En términos de dominio son tus contextos acotados; en términos de equipo suelen ser quién es dueño de qué. Pedidos, Pagos, Identidad, Catálogo. Dibújalos como regiones con nombre y mete los servicios dentro. De repente el diagrama tiene estructura, y el lector puede recorrerlo por áreas en lugar de escanear cuarenta cajas idénticas.
Muestra la comunicación síncrona y asíncrona en cada arista
No todas las flechas son iguales, y fingir que lo son es la razón por la que los diagramas de microservicios engañan. Una petición síncrona (un servicio llama a otro y espera) tiene un comportamiento de fallos y de latencia completamente distinto al de un evento asíncrono (un servicio publica y los demás reaccionan cuando sea). Dibújalos de forma distinta: líneas continuas para las llamadas síncronas, discontinuas para los eventos a través de un bus o una cola. Ahora el diagrama cuenta una historia operativa. Puedes ver dónde un servicio lento provocará un efecto en cascada (las cadenas continuas) y dónde el sistema está desacoplado (los saltos discontinuos).
Dos tipos de flecha, dibujados de forma distinta, convierten una maraña en un mapa de dónde se propaga un fallo y dónde se detiene.
Dibuja la propiedad de los datos, al menos una vez
La regla que hace que los microservicios sean microservicios es que cada servicio es dueño de sus datos. Un diagrama que muestra a todos los servicios compartiendo una base de datos está dibujando un monolito distribuido, lo pretenda el equipo o no. Vale la pena tener una vista en la que cada servicio aparezca con su propio almacén, porque en cuanto dos servicios apuntan a la misma base de datos, has encontrado un acoplamiento que te dolerá más adelante. No lo necesitas en todos los diagramas, pero lo necesitas en alguno.
Añade los elementos que son de todos
Algunos componentes quedan fuera de los límites y lo tocan todo: el API gateway que está delante de todo el sistema, el bus de eventos o message broker que transporta el tráfico asíncrono y, si usas una, la service mesh que gestiona la comunicación entre servicios. Dales su propio sitio en los bordes del diagrama para que se lean como infraestructura compartida y no como un servicio más dentro de una caja.
Resiste la tentación de dibujarlo todo
El diagrama de microservicios fallido intenta ser completo. El útil es parcial a propósito. Elige la pregunta que responde el diagrama (cómo fluye una petición, dónde están los límites asíncronos, qué servicios son dueños de qué datos) y dibuja solo lo que sirve para responderla. Completo pero ilegible no ayuda a nadie; enfocado y claro es justo lo que se busca.
Mantenlo vivo
Los sistemas de microservicios cambian más rápido que casi cualquier otra cosa que puedas diagramar: servicios nuevos, eventos nuevos, dependencias retiradas. Una versión dibujada a mano está desactualizada antes de que acabe el sprint. Deriva el esqueleto de la fuente (especificaciones, manifiestos de servicios o un grafo de llamadas), regenéralo a medida que evoluciona y mantén tu agrupación por límites y el estilo de las aristas como la capa humana por encima. Así el diagrama sigue el ritmo de un sistema cuya promesa entera es cambiar de forma independiente.
Agrupa por límite, da estilo a las aristas según cómo se comunican los servicios, muestra la propiedad de los datos una vez y genera la base para que siga actualizada. Ese es un diagrama de microservicios que aclara en lugar de intimidar.