Los archivos como un nuevo recurso
DWall ya tenía soporte para subir y bajar archivos contra Google Cloud Storage antes de este capítulo. Lo que no existía era el archivo como recurso de DWall: una entidad con identidad propia, dueño, tipo y estado, equiparable a una variable, una regla o una consulta. Los archivos vivían como blobs sueltos sobre los que la plataforma no tenía nada que decir más allá de "esto está en GCS".
Este capítulo es el que cambia esa situación. A partir de aquí, un archivo subido por un usuario deja de ser un binario anónimo y pasa a ser un recurso de primera clase, con todo lo que eso implica en una plataforma DDD: un agregado raíz (FileResource), un identificador, un ciclo de vida y un sitio en el resto del sistema.
Qué significa elevar el archivo a recurso
En la práctica eso se traduce en un módulo Maven nuevo, dwall-module-files, que vive al mismo nivel que dwall-module-variable, dwall-module-query o dwall-module-rule dentro del backend. Sigue la misma estructura hexagonal del resto: un files-domain con el agregado y los puertos, un files-app con el servicio que orquesta la subida, y un files-persistence con el adaptador que escribe en PostgreSQL. Un módulo más en la familia, no una excepción al diseño.
Interfaz mejorada de listado de archivos.
En ese mismo contexto crearemos el agregado FileResource el cual carga los mismos atributos que cualquier recurso de DWall: un FileId propio, un OwnerId que lo asocia al usuario que lo subió, un FileName, un ContentType que mapea al MIME, un ResourceType que clasifica el archivo dentro del catálogo de la plataforma y un BucketPath que apunta a su ubicación física en GCS. Encima de eso lleva un FileStatus — PENDING, READY o ERROR — que refleja en qué punto del flujo de subida y procesado se encuentra.
Interfaz mejorada de subida de archivos.
Al modelarlo así, el archivo entra en los mismos rieles que el resto del catálogo. Hereda el control de acceso por usuario, encaja con el sistema de descripciones, y, sobre todo, se vuelve embebible: si el cliente lo activa, el contenido del archivo se puede procesar para alimentar la búsqueda semántica del capítulo anterior. El embedding no es obligatorio — un archivo puede vivir solo como blob registrado en DWall —, pero cuando se activa el sistema gana una capacidad nueva que el módulo de embeddings clásico no podía dar.
Ambas interfaces, creadas durante el periodo de prácticas, incorporan mejoras sustanciales aprendidas durante el capítulo EPL de evolución de plataforma. Este mismo detalle hace que no sea necesario mucho más detalle al respecto, simplemente la lógica de almacenar archivos como recurso simplifican las páginas observables, mientras que las mejoras del EPL mejoran tambien el rendimiento.
El plus: búsqueda semántica sobre el contenido
La búsqueda semántica que se construyó en el capítulo BDV operaba sobre las descripciones de los recursos (y los datos de los recursos en si). Funcionaba bien para variables, reglas o consultas porque sus descripciones son cortas y caben en un único vector. Pero un manual de operación, un procedimiento de mantenimiento o un informe de incidencia no se pueden resumir así sin perder lo que les hace útiles. Si el archivo es un recurso embebible, lo que se proyecta al espacio vectorial no es su descripción — es su contenido troceado en fragmentos —, y eso permite que el operador pregunte por "la temperatura máxima admisible para el compresor IGE12" y reciba el pasaje exacto de la página 47 del PDF del fabricante en lugar de tener que abrirlo y buscarlo a mano.
Esa es la diferencia que justifica todo el capítulo. El siguiente entra en cómo se reparte el trabajo entre los tres módulos que intervienen y cuáles son los dos puertos que los conectan.