Diagramas del curso#

Hay 7 mapas generales y 18 diagramas enfocados, uno por cada lección. Los mapas generales orientan la ruta estratégica y los límites de arquitectura; cada lección enlaza su propio SVG enfocado fiel al bloque Mermaid inline para que el mismo modelo pueda estudiarse sin necesidad de un renderizador dinámico. Las fuentes .mmd son copias idénticas del bloque Mermaid correspondiente. Son modelos formales de trabajo, no especificaciones de una aplicación comercial específica.

Para consultar el significado exacto de cualquier concepto de software representado en estos diagramas, consulta el glosario técnico general.

Diccionario de notación visual y lectura de diagramas#

Para interpretar estos modelos con exactitud matemática y sin ambigüedades, este glosario desglosa los cuatro principios visuales fundamentales utilizados en toda la iconografía del curso:

1. Nodos de proceso frente a Nodos de decisión#

• Nodos rectangulares [Proceso / Estado]: Representan una etapa determinista, una transformación secuencial o una mutación atómica de estado en el sistema. Al entrar a este nodo, la acción se ejecuta de forma unívoca sin bifurcación interna.
• Nodos romboidales {¿Decisión / Validación?}: Representan una bifurcación lógica gobernada por un predicado booleano o la coincidencia de un patrón exhaustivo. Disponen de dos o más flechas de salida etiquetadas explícitamente (ej. |Sí|, |No|, |Ok|, |Err|). Cada rama conduce a un estado mutuamente excluyente.
• Qué NO es: Un nodo de decisión no crea datos nuevos; solo evalúa una condición observable existente y dirige el flujo de control hacia el destino adecuado.

2. Diagrama de flujo (flowchart) vs Diagrama de secuencia temporal (sequenceDiagram)#

• Diagrama de flujo (flowchart TD / flowchart LR): Modela la topología causal de un algoritmo o máquina de estados: bifurcaciones, condiciones de error, bucles de reintento y convergencias de flujo. La posición vertical u horizontal representa relaciones lógicas de causa y efecto, no necesariamente el paso del tiempo cronológico absoluto.
• Diagrama de secuencia temporal (sequenceDiagram): Modela la interacción cronológica entre múltiples participantes o procesos autónomos a través del tiempo. El tiempo transcurre de forma estricta de arriba hacia abajo. Las flechas horizontales representan mensajes, peticiones de red o llamadas a funciones, y las líneas punteadas representan respuestas que retornan a la entidad que originó la petición.
• Qué NO es: Un diagrama de secuencia no debe usarse para modelar dependencias estáticas de código entre clases o traits; está reservado para la coreografía de mensajes en tiempo de ejecución.

3. Flecha de flujo de datos en tiempo de ejecución vs Flecha de dependencia de código en tiempo de compilación#

• Flecha de flujo de datos en runtime (longrightarrow): Indica la dirección física en la que viajan los paquetes de red, los bytes en memoria o los argumentos de llamada entre dos componentes activos durante la ejecución del programa (ej. del navegador al backend, o del backend al motor de base de datos).
• Flecha de dependencia de código en tiempo de compilación (dashrightarrow o uso de traits): Indica qué módulo conoce y se acopla a las interfaces de otro módulo a nivel de código fuente. En una arquitectura limpia con Inversión de Dependencias (DIP), la flecha de dependencia de código apunta con frecuencia en sentido inverso al flujo físico de los datos: el adaptador de base de datos depende del contrato del dominio, pero en runtime los datos fluyen del dominio al adaptador.
• Qué NO es: La dirección en la que viajan los datos en tiempo de ejecución no define quién debe compilar primero o quién depende de quién en el diseño de módulos.

4. Frontera de confianza / Límite arquitectónico#

• Subgrafos y cajas de límite (subgraph Boundary): Delimitan zonas del sistema con diferentes niveles de confianza, diferentes ritmos de cambio o diferentes tecnologías. Todo dato que atraviesa una frontera de confianza proviene de un medio potencialmente hostil o no tipado (cadenas de red JSON, entradas de usuario o parámetros de consulta) y debe someterse a parseo y validación de invariantes antes de ingresar al núcleo interno de dominio.
• Qué NO es: Una frontera no es un simple agrupador cosmético de dibujo; representa un punto de desacoplamiento formal donde se traducen DTOs externos a tipos ricos del dominio.

Mapas generales#

00 · Mapa del curso: seis tramos y un ciclo de práctica#

• Cómo leer este diagrama paso a paso:

1. Comienza en el nodo superior de inicio del Módulo 00 y sigue la secuencia descendente a través de los cinco módulos temáticos.
2. Observa cómo cada módulo descansa estrictamente sobre las garantías del módulo anterior: el backend asume la seguridad de memoria de Rust; el frontend interactúa con los contratos HTTP del backend; el diseño refactoriza el código full-stack; y la operación blinda el despliegue y la seguridad.
3. En cada etapa, el flujo no avanza por lectura pasiva, sino al completar el ciclo iterativo de práctica empírica: escribir predicción → ejecutar compilación/prueba → registrar evidencia observable.

• Preguntas de autoevaluación visual:
• ¿Por qué el estudio de bases de datos relacionales y concurrencia asíncrona se aborda en el Módulo 02 solo después de dominar ownership y traits en el Módulo 01?
• ¿Qué bucle de retroalimentación en el diagrama previene avanzar con conceptos no comprendidos?

01 · Ownership y ciclo de vida de memoria en Rust#

• Cómo leer este diagrama paso a paso:

1. Observa la creación de un recurso en el heap y la asignación inicial de su puntero de propiedad en el stack a una variable dueña.
2. Sigue la bifurcación entre un préstamo compartido (&T, múltiples lectores concurrentes), un préstamo exclusivo (&mut T, mutación aislada y única) y una transferencia de propiedad (move).
3. Comprueba el punto de salida de ámbito (scope end): si la variable es dueña del recurso, el compilador ejecuta deterministamente Drop::drop; si la variable cedió su propiedad por un movimiento previo, el compilador omite la llamada evitando una doble liberación.

• Preguntas de autoevaluación visual:
• ¿En qué parte del diagrama se observa la ley de exclusión mutua: lectura concurrente XOR mutación exclusiva?
• ¿Qué camino del diagrama conduce al error de compilación E0382 (use of moved value)?

02 · Ciclo de vida completo de una solicitud HTTP backend#

• Cómo leer este diagrama paso a paso:

1. Identifica el punto de entrada de la solicitud HTTP cruda a través del socket TCP administrado por el worker de Actix Web.
2. Sigue el cruce de la frontera de transporte: los extractores (web::Json, web::Path) analizan y deserializan la carga útil, rechazando inmediatamente peticiones mal formadas con errores 400 Bad Request.
3. Observa cómo el handler invoca la capa de servicio de dominio, la cual inicia una transacción SQL con la base de datos PostgreSQL, ejecuta la mutación y retorna un resultado estructurado que se transforma en una respuesta HTTP (200 OK o 201 Created).

• Preguntas de autoevaluación visual:
• ¿En qué etapa del diagrama se garantiza que los datos entrantes satisfacen los tipos de Rust antes de ejecutar cualquier lógica de negocio?
• ¿Qué camino sigue la solicitud si la base de datos rechaza la mutación por una violación de restricción UNIQUE?

03 · Transacciones concurrentes e invariantes de unicidad#

• Cómo leer este diagrama paso a paso:

1. Sigue las líneas temporales de dos transacciones concurrentes (Tx1 y Tx2) que intentan registrar de forma simultánea la misma clave de negocio (ej. el mismo correo electrónico o nombre de usuario).
2. Observa el fallo catastrófico del enfoque ingenuo con SELECT previo: ambas transacciones comprueban que la clave "no existe aún" y ambas intentan insertar, provocando una carrera de tiempo de verificación a tiempo de uso (TOCTOU).
3. Observa el camino seguro mediante la restricción UNIQUE del motor PostgreSQL: la primera transacción en confirmar adquiere el cerrojo del índice B-Tree, mientras que la segunda transacción es rechazada de forma determinista con un error de restricción, abortando atómicamente con ROLLBACK.

• Preguntas de autoevaluación visual:
• ¿Por qué un bloqueo en memoria en el servidor backend no previene este conflicto si existen dos servidores independientes detrás de un balanceador de carga?
• ¿Cómo se garantiza la durabilidad del registro insertado una vez emitido el COMMIT?

04 · Reconciliación de estado, efectos y respuestas asíncronas en el navegador#

• Cómo leer este diagrama paso a paso:

1. Observa el evento de entrada del usuario que activa una actualización del estado local en React mediante useState.
2. Sigue el renderizado de la nueva instantánea visual (render snapshot) y la activación subsiguiente del hook useEffect con la petición de red asíncrona hacia el backend.
3. Rastrea la bifurcación crítica ante respuestas fuera de orden: si el usuario modifica nuevamente la entrada antes de que llegue la primera respuesta, el AbortController cancela la petición pendiente o la bandera de limpieza descarta el resultado viejo, evitando que datos obsoletos sobrescriban la interfaz activa.

• Preguntas de autoevaluación visual:
• ¿Qué componente del diagrama asegura que una búsqueda con texto viejo que demoró 500 ms en red no reemplace el resultado de una búsqueda fresca que tardó 50 ms?
• ¿Por qué el estado derivado no se almacena en un segundo useState dentro de este modelo?

05 · Bucle disciplinado de refactorización y corrección de defectos#

• Cómo leer este diagrama paso a paso:

1. Distingue con absoluta claridad los dos caminos de inicio: - Camino de Bugfix: Comienza en un estado de fallo o ausencia de comportamiento. Se escribe una prueba que falla en rojo (RED), se implementa el cambio mínimo de producción hasta pasar a verde (GREEN), y luego se estabiliza. - Camino de Refactorización: Comienza obligatoriamente en un estado de comportamiento comprobado y verde (GREEN). Se aplican micro-transformaciones estructurales preservando el estado GREEN en cada paso intermedio sin modificar las aserciones de prueba.
2. Identifica el bucle de reversión: si un cambio estructural causa que una prueba falle, la regla disciplinaria no es "parchear la prueba", sino revertir el último cambio de código al commit anterior verificado.

• Preguntas de autoevaluación visual:
• ¿Por qué mezclar la corrección de un error funcional con una refactorización de arquitectura en el mismo commit destruye la trazabilidad diagnóstica?
• ¿Qué garantiza que una refactorización no alteró inadvertidamente el contrato público del software?

06 · Seguridad en profundidad, observabilidad y entrega continua#

• Cómo leer este diagrama paso a paso:

1. Identifica las capas concéntricas de defensa en profundidad: red perimetral TLS → control de cabeceras de origen (CORS) → autenticación de sesión con cookies HttpOnly y Secure → autorización de privilegios por objeto (anti-BOLA) → parametrización estricta de consultas SQL.
2. Sigue la propagación del identificador de correlación (Correlation ID o Trace ID) desde la cabecera HTTP inicial a través de los logs estructurados del backend hasta los registros de auditoría de la persistencia.
3. Observa el ciclo de despliegue con migración Expand-and-Contract: el nuevo esquema de datos se añade de forma compatible antes de encender el nuevo contenedor backend, permitiendo rollback instantáneo de binario sin corrupción de datos.

• Preguntas de autoevaluación visual:
• ¿En qué punto del diagrama se previene la vulnerabilidad de BOLA / IDOR?
• ¿Por qué el control de salud Readiness se desconecta antes de que el proceso reciba una señal de apagado ordenado (SIGTERM)?

Diagramas enfocados por lección#

Cada una de las 18 lecciones del curso dispone de un modelo visual formal enfocado en el mecanismo central abordado en dicha etapa.

Cómo utilizar los diagramas como herramientas activas de estudio#

Los diagramas de secuencia conservan participantes autónomos, orden cronológico descendente y dirección exacta de cada mensaje. Los diagramas de flujo conservan ramas condicionales, retornos y rutas alternativas del diseño original.

Para convertir un diagrama en un instrumento de aprendizaje activo:

1. Oculta temporalmente la explicación textual de la lección y describe en voz alta el flujo de estados siguiendo las flechas de inicio a fin.
2. Formula una hipótesis de fallo: "¿Qué ocurre en este nodo si la base de datos devuelve un timeout?" o "¿Qué camino sigue el sistema si el usuario desconecta el cable de red?".
3. Verifica la predicción: Comprueba si el modelo visual contempla una rama de recuperación o si detectas una debilidad estructural en el diseño que requiere modelado adicional.