En el mundo del desarrollo de software y la arquitectura de sistemas, mostrar toda la información en un único diagrama puede parecer práctico al principio, pero suele convertirse en un desafío para quienes necesitan entenderlo. Los diagramas maestros que intentan abarcar todos los aspectos de un sistema complejo suelen ser excesivamente densos y difíciles de interpretar, provocando confusión en lugar de claridad. Para enfrentar este problema, surge como solución la práctica de dividir el diagrama maestro en múltiples perspectivas que expliquen distintos aspectos del sistema, facilitando así su análisis y comunicación. Un claro ejemplo de esta problemática y solución se encuentra en la descripción de la arquitectura back-end serverless de Ilograph, desplegada en Amazon Web Services (AWS). Este sistema maneja operaciones CRUD para la aplicación web, además de integrar el escritorio y una API de exportación.
A simple vista, su diagrama maestro muestra una gran cantidad de recursos y flujos entre ellos, incluyendo clientes, API Gateway, funciones Lambda, bases de datos y múltiples servicios de AWS y terceros. Esta amalgama resulta en una imagen compleja, con líneas que se cruzan, etiquetas que se omiten por su número y cantidades de detalles que abruman a cualquier observador. Para mejorar la legibilidad y utilidades del diagrama, se propone dividirlo en cuatro perspectivas claras. Cada perspectiva ofrece una mirada particular y específica, resaltando diferentes relaciones y componentes del sistema. Esta forma de descomponer la imagen facilita la comprensión profunda sin la necesidad de procesar todo al mismo tiempo.
La primera perspectiva es la de dependencia en tiempo de ejecución, que se centra en mostrar cómo los recursos interactúan cuando el sistema está activo y procesando datos dinámicos. Aquí se visualizan los clientes que acceden a la API Gateway, el almacenamiento en buckets S3 y tablas de DynamoDB, así como las funciones Lambda que contienen la lógica de negocio que coordina estas interacciones. Esta vista permite identificar claramente la arquitectura de tres niveles y la dependencia externa de Stripe para pagos. La segunda perspectiva se denomina dependencia en tiempo de despliegue. A diferencia de la anterior, esta se concentra en el código que ejecutan las funciones Lambda.
Expone la organización del código fuente, que en este caso está escrito en Typescript y almacenado en un repositorio Git, así como cómo las funciones Lambdas invocan otras funciones y sus dependencias en librerías externas de npm. Esta perspectiva es fundamental para entender el diseño, la modularidad y las relaciones internas del software antes de ser desplegado en producción. Separar las dependencias de ejecución y despliegue ayuda a clarificar que algunos componentes son críticos solo en fases específicas del ciclo de vida del software. Por ejemplo, las conexiones a Git o npm son esenciales en la etapa de despliegue, pero no durante la ejecución en producción. La tercera perspectiva se ocupa de las relaciones entre recursos estáticos, que en la arquitectura de Ilograph corresponden a archivos HTML, JavaScript y otros elementos estáticos que soportan la aplicación web y la página de información.
Estos archivos se distribuyen mediante servicios como CloudFront respaldados por buckets S3, y también se incluyen configuraciones DNS, tanto en Route53 como en Namecheap, junto con servicios de correo electrónico en SES y Workmail. Esta perspectiva enfatiza el manejo y configuración de recursos que no cambian con frecuencia y no forman parte de la lógica dinámica del sistema. Por último, la cuarta perspectiva se enfoca en funcionalidades especiales relacionadas con eventos de usuario, como registro o inicio de sesión. Las funciones Lambda son activadas por triggers procedentes de Cognito para enviar correos de bienvenida o realizar otras tareas administrativas sencillas. Este tipo de operaciones se distancian conceptualmente de la lógica del API principal y requieren ser vistas aparte para su mejor entendimiento.
Una idea clave en la creación de diagramas de arquitectura es diferenciar entre diagramas maestros y diagramas de alto nivel. Mientras que los primeros intentan mostrar todos los aspectos del sistema, los diagramas de alto nivel simplifican examinando solo las relaciones más generales y agrupando recursos similares. Por ejemplo, la versión simplificada de la perspectiva de tiempo de ejecución puede mostrar solo las interacciones entre servicios como Lambda, DynamoDB y API Gateway, sin entrar en detalles de funciones o tablas específicas. Otra ventaja de dividir el diagrama maestro en perspectivas reside en la capacidad de ampliar detalles en cada una de ellas sin saturar al lector. Los diagramas individuales son más accesibles, pueden incluir más etiquetas y nombres claros, y evitan la ambigüedad que surge cuando demasiados elementos se solapan entre sí.
Este método también contribuye a un cambio mental importante en los espectadores técnicos. Les libera de la presión de comprender de inmediato todo el sistema en su totalidad, promoviendo un aprendizaje incremental y más efectivo. Reconocer que no es necesario ver la arquitectura completa como un único bloque es esencial para abordar sistemas complejos de manera práctica. Además, el enfoque por perspectivas ayuda a distribuir responsabilidades entre equipos. Por ejemplo, los desarrolladores de backend pueden enfocarse en la perspectiva de dependencias en tiempo de ejecución y despliegue, mientras que los especialistas en infraestructura o redes pueden manejar la perspectiva de DNS y recursos estáticos, y el equipo de experiencia del usuario puede atender la perspectiva de triggers relacionados con la autenticación.
En definitiva, desglosar un diagrama maestro en varias perspectivas es una práctica recomendada para cualquier sistema complejo, sobre todo en arquitecturas distribuidas o serverless. Esta técnica facilita a profesionales y stakeholders la comprensión del sistema, mejora la documentación, agiliza la comunicación y reduce errores derivados de malentendidos. En el contexto moderno, donde los sistemas usan múltiples servicios en la nube, funciones sin servidor y componentes distribuidos, la claridad es prioridad. Los diagramas segmentados permiten captar los detalles esenciales sin perderse en la complejidad inherente. Por último, el uso de herramientas que soportan diagramas interactivos o con diferentes capas, como algunas que permiten ocultar o revelar detalles a demanda, puede potenciar aún más las ventajas de esta aproximación y fomentar la colaboración entre equipos técnicos.
Frente a la complejidad, la simplicidad y la segmentación estructurada ayudan a construir plataformas más robustas, comprensibles y eficientes. Dividir el diagrama maestro en perspectivas definidas es un paso fundamental para lograrlo, marcando la diferencia entre un sistema intimidante y uno accesible y manejable.
