Un diagrama de contexto del sistema en C4 responde a una pregunta sencilla: ¿qué hace este sistema de software, quién lo utiliza y con qué otros sistemas se relaciona? Debe permitir entender sus límites antes de entrar en los detalles de implementación.
Si empiezas con una plantilla de diagrama de arquitectura de Boardmix, lo primero es decidir esos límites. En este ejemplo representaremos una plataforma de reservas que utilizan clientes y coordinadores del servicio. Dejaremos fuera las pantallas, las bases de datos y la infraestructura de despliegue.
Define de qué se ocupa la plataforma de reservas
La guía de diagramas de contexto del modelo C4 sitúa en el centro un sistema de software y muestra las personas y los sistemas externos conectados directamente con él. Es una vista general: importan más los usuarios y las responsabilidades que los protocolos o los componentes internos.
Imagina una plataforma que permite a los clientes reservar citas para un servicio y a los coordinadores gestionar la disponibilidad. Además, solicita el procesamiento de pagos a un servicio externo, envía solicitudes de entrega a un servicio de correo electrónico y publica cambios en las reservas en un sistema de calendario externo.
Escribe una descripción breve dentro del bloque central: Plataforma de reservas: gestiona la disponibilidad, las reservas y sus cambios. Resulta más útil que un bloque llamado «Backend», que indica una posición técnica sin explicar la finalidad del sistema.
Dentro del sistema quedan tanto la aplicación para clientes como la de coordinadores. Fuera quedan los servicios de pagos, correo electrónico y calendario, que funcionan de forma independiente. Ser responsable del código de una integración no equivale a ser responsable del servicio al que se conecta; representa ambas responsabilidades por separado.
Enumera las relaciones antes de distribuir los bloques
Empieza con un inventario breve. Así evitarás que la búsqueda de una composición ordenada deje fuera a un actor o una dependencia importante. Añade un elemento solo cuando puedas explicar su relación con el sistema que estás describiendo.
| Elemento | Papel en el ejemplo | Etiqueta de la relación |
|---|---|---|
| Cliente | Persona que hace y modifica una reserva | Reserva y cambia citas |
| Coordinador del servicio | Persona que gestiona la programación del servicio | Gestiona disponibilidad y reservas |
| Servicio de pagos | Sistema externo que procesa las solicitudes de pago | Solicita el procesamiento del pago |
| Servicio de correo | Sistema externo que entrega los mensajes sobre reservas | Solicita el envío de mensajes de reserva |
| Sistema de calendario | Sistema externo que recibe cambios en las reservas | Publica cambios en las reservas |
Las dos primeras relaciones van de la persona a la plataforma. Las tres restantes van de la plataforma al sistema externo. Las etiquetas explican la interacción en ese sentido, no cada solicitud y cada respuesta.
Por ejemplo, «Solicita el procesamiento del pago» puede representar el uso del servicio de pagos sin añadir una segunda línea para cada respuesta. Si una notificación de pago asíncrona es importante para la conversación sobre arquitectura, dibuja y etiqueta esa relación por separado. Una flecha de doble sentido con la palabra «datos» no aclara qué significa la conexión.
Decide qué queda fuera de esta vista
Revisa ahora los elementos que el equipo suele querer añadir. Una base de datos es importante para la aplicación, pero eso no la convierte en otro sistema externo. En este ejemplo, la base de datos de reservas forma parte de la plataforma y corresponde a una vista más detallada.
| Elemento propuesto | Decisión para el diagrama de contexto | Vista adecuada |
|---|---|---|
| Base de datos de reservas | Mantenerla dentro de la abstracción del sistema central. | Diagrama de contenedores con las aplicaciones y los almacenes de datos de la plataforma |
| Pantalla de acceso del cliente | No representar una pantalla como un sistema de software independiente. | Flujo de usuario o diseño de pantallas |
| Balanceador de carga y réplicas | Excluir la topología de despliegue. | Vista de despliegue del entorno correspondiente |
| Personal de atención al cliente | Añadirlo solo si ese rol utiliza la plataforma o interactúa directamente con ella dentro del alcance definido. | Diagrama de contexto, si existe esa relación directa |
| Plataforma contable que solo recibe un informe introducido a mano | No inventar una integración directa entre sistemas. | Descripción separada del traspaso operativo, si es relevante |
El último caso importa porque una flecha puede dar a entender que existe una conexión que nadie ha implementado. Si un coordinador exporta información y la introduce manualmente en otra herramienta, no es lo mismo que una transmisión desde la plataforma. Describe lo que sucede y distingue las integraciones previstas de las existentes.
Puedes representar un estado futuro, pero indícalo en el título. No mezcles una conexión de pagos en funcionamiento y una conexión de calendario propuesta sin explicar la diferencia.
Usa etiquetas que se entiendan después de la reunión
La guía de notación de C4 recomienda descripciones comprensibles, etiquetas en las relaciones y una leyenda. Puedes elegir el estilo visual, pero el lector no debería tener que adivinar si un bloque gris es externo, opcional o simplemente no está seleccionado.
Da al diagrama un título concreto: «Plataforma de reservas: contexto del sistema: piloto propuesto». Añade una leyenda que distinga personas, sistema analizado y sistemas externos. Mantén los términos de la documentación del proyecto. Si el equipo habla de un «coordinador del servicio», cambiarlo por «administrador» puede introducir otras responsabilidades.
Las descripciones deben ser breves y comprensibles sin abrir otro documento. «Servicio de correo: entrega confirmaciones y avisos de cambios» explica más que el logotipo de un proveedor. El logotipo puede identificar quién presta el servicio, pero no por qué existe la dependencia.
No interpretes cada línea como un paso cronológico. El contexto muestra relaciones, no el orden exacto de una reserva. La pregunta «¿se paga antes de confirmar?» requiere una vista del comportamiento, no una etiqueta más larga en este diagrama.
Dibuja el contexto de las reservas en Boardmix
Coloca la plataforma en el centro del lienzo de Boardmix. Sitúa a las dos personas a un lado y a los tres sistemas externos al otro, con espacio suficiente para las etiquetas. Utiliza formas sencillas y conectores: el significado está en los nombres, las descripciones y los límites, no en un icono de servidor llamativo.
Añade las cinco relaciones del inventario de una en una. Lee cada una desde el origen hasta el destino: «El cliente reserva y cambia citas en la plataforma de reservas». Si la frase no se entiende, corrige la etiqueta antes de añadir otra flecha.
Junto al diagrama, reserva una zona para preguntas sobre el alcance. Por ejemplo: «¿El coordinador actualiza el calendario directamente o lo hace la plataforma?». No resuelvas esa duda dibujando ambas rutas como si las dos estuvieran confirmadas.
Abre una pizarra de Boardmix para representar el contexto de tu sistema. Reúne a quienes conocen el trabajo de los usuarios y a quienes conocen las dependencias técnicas: suelen detectar omisiones distintas en el mismo dibujo.
Añade detalle sin cambiar el significado del primer diagrama
Una vez acordado el contexto, un diagrama de contenedores C4 puede mostrar las aplicaciones y los almacenes de datos de la plataforma. Aquí «contenedor» es una abstracción de C4, no una obligación de utilizar Docker ni otro entorno de ejecución de contenedores.
En la siguiente vista, el bloque de la plataforma puede desglosarse en una aplicación de clientes, otra de coordinadores, un servicio de aplicación y un almacén de reservas. Conserva los nombres de los sistemas externos de pagos, correo y calendario. El segundo diagrama amplía el primero; no debería introducir por sorpresa unos límites de producto distintos.
Si el equipo no se pone de acuerdo sobre si el calendario pertenece a la plataforma o es externo, resuelve esa cuestión antes de seguir. Un dibujo más detallado no aclara por sí solo una responsabilidad pendiente. Define los límites y elige después la vista que responda a la siguiente pregunta.
