Arquitectura de e-commerce, modelada

Una tienda es el ejemplo al que recurre todo el mundo, y la razón de que la mayoría de los diagramas de tienda sean inútiles es que intentan ser una sola imagen. El vocabulario, las fronteras de servicio y las máquinas son tres temas distintos, y un dibujo que los mezcla no responde a ninguno: es ese diagrama con una clase Order, un logo de Kubernetes y una cola en el mismo lienzo.

Separados por pregunta, cada uno se vuelve comprobable:

1. ¿Cuáles son los sustantivos? Un diagrama de clases del dominio. Qué es un pedido, de qué se compone, sin qué no puede existir.
2. ¿Quién puede llamar a quién? Un diagrama de componentes de los servicios y los contratos entre ellos.
3. ¿Dónde se ejecuta? Un diagrama de despliegue de los nodos y los artefactos que hay en ellos.

Nada de esto es un diagrama de colas, uno de secuencia ni un listado de infraestructura como código, y es a propósito. Esos existen y son útiles; también son donde un conjunto de documentación se muere si los tres primeros no están bien.

Este es el diagrama que asienta el vocabulario, y el vocabulario es donde las tiendas se tuercen primero. ¿Es un "carrito" una Order que aún no se ha realizado, o una cosa distinta? ¿Guarda una OrderLine el precio en el momento de la compra, o lo lee del Product? La segunda pregunta la responde la figura - unitPrice vive en la línea - y ese único atributo es la diferencia entre una tienda cuyas facturas antiguas siguen siendo correctas tras un cambio de precios y otra cuyas facturas no lo son.

La figura de la cabecera de este artículo. Dos clientes, un servicio de pedidos y dos contratos de los que depende: existencias y pago. Léelo tapando una caja: tapa el servicio de pedidos y lo que queda es IOrders, IStock e IPayment, que es exactamente la especificación que tendría que cumplir un sustituto.

El adaptador es la pieza que merece copiarse. IPaymentes un contrato que la tienda posee; el adaptador de Stripe lo realiza. Nada del servicio de pedidos nombra a un proveedor, así que "¿qué costaría cambiar a Adyen?" tiene una respuesta que puedes ver: una caja y lo que resulte que el adaptador haya dejado escapar. Dibujado al revés, con el servicio de pedidos dependiendo directamente de un componente de Stripe, la misma pregunta necesita una búsqueda en el código.

Lo que falta a propósito: el carrito, el índice de búsqueda, el motor de recomendaciones, el envío de correos. Todos son reales, y ninguno cambia la respuesta a "quién puede llamar a quién en la ruta de compra". Van a su propio diagrama, cuando alguien tenga una pregunta sobre ellos.

Este es el diagrama que nadie dibuja hasta el primer incidente, y el que responde a preguntas que los otros dos no pueden: qué es alcanzable desde internet, qué habla con la base de datos, y dónde está la frontera con un tercero. La API de Stripe se dibuja como nodo externo precisamente porque no es tuya: la caja recuerda que su disponibilidad es una dependencia que no controlas.

Es además el único de los tres que se queda obsoleto un martes cualquiera. El modelo de dominio sobrevive intacto a un cambio de plataforma y la vista de componentes también; el diagrama de despliegue lo invalida una migración de clúster. Esa asimetría es una buena razón para tenerlo aparte en vez de plegar "corre en Kubernetes" dentro de las cajas de componentes.

La notación que hay detrás del diagrama del medio, con cinco topologías más, está en los ejemplos de diagramas de componentes. Para producir un primer borrador de cualquiera de los tres a partir de una descripción en vez de a mano, mira generar UML con IA.