Middleware ETL: Generación de productos independiente del framework para e-commerce

Contexto del Proyecto

Un proyecto B2B para un retailer textil centrado en integrar datos analíticos expuestos a través de Power BI en múltiples tiendas Magento. En lugar de tratar Magento como el núcleo de la lógica de negocio, se decidió externalizar y centralizar la complejidad del dominio en un middleware dedicado, posicionando Magento como un consumidor descendente responsable solo de la ejecución comercial. Este enfoque permitió que el sistema evolucionara independientemente del modelo de datos interno de Magento y sus mecanismos de importación.

Desafío Técnico

El desafío principal fue la fase de Transformación del proceso ETL, donde los datos analíticos necesitaban convertirse en productos comerciales completos.

Esto requería:

• • Interpretar conjuntos de datos de Power BI
• • Aplicar reglas de negocio complejas y en evolución
• • Generar definiciones completas de productos: atributos y conjuntos de atributos, productos configurables y variaciones, lógica de precios y restricciones específicas del sector textil

Dada la naturaleza crítica de esta lógica, la corrección, la predictibilidad y la capacidad de prueba eran tan importantes como la completitud funcional.

Solución Arquitectónica

La solución fue un middleware ETL personalizado construido usando Domain-Driven Design y Arquitectura Hexagonal (Puertos y Adaptadores).

• • Núcleo hexagonal e independencia del framework: En el centro se encuentra una capa de dominio pura, libre de dependencias de frameworks e infraestructura. El Dominio define entidades y Objetos de Valor, Casos de Uso que representan transformaciones ETL, y contratos de salida (Puertos) que describen los resultados de las transformaciones. Las preocupaciones de infraestructura se empujan hacia afuera y se conectan a través de adaptadores, asegurando que el dominio permanezca estable incluso si la tecnología circundante cambia.
• • Puertos, Adaptadores y efectos secundarios controlados: Todas las interacciones externas se manejan a través de Puertos definidos en el Dominio y Adaptadores implementados en la capa de Infraestructura. Este enfoque permite múltiples implementaciones concretas, reemplazo fluido de frameworks (Laravel, Symfony, etc.), y efectos secundarios controlados y explícitos. Las recetas de Inyección de Dependencias conectan el sistema sin filtrar infraestructura al dominio.
• • ETL como flujo de trabajo orientado al dominio: El proceso ETL se modeló como un flujo de trabajo de negocio, no como un script técnico: extracción y normalización de datos en DTOs, ejecución de Casos de Uso de dominio, aplicación de reglas de negocio, y emisión de Resultados normalizados a través del Patrón de Resultado. Los importadores de Magento consumen estos resultados de forma asíncrona mediante trabajos cron.

Estrategia de Pruebas y Calidad

Las pruebas y la calidad fueron preocupaciones de primera clase, habilitadas directamente por la arquitectura hexagonal.

• • Pruebas a nivel de dominio: La capa de Dominio es completamente probable de forma aislada. No se requiere inicialización de framework, no hay base de datos, sistema de archivos o servicios externos involucrados. Las pruebas se centran en reglas de negocio, corrección de transformaciones, casos límite y escenarios de validación.
• • Sustitución de adaptadores para pruebas: Se inyectaron adaptadores simplificados o falsos durante las pruebas. El comportamiento de la infraestructura podía simularse de forma determinista, permitiendo una ejecución de pruebas rápida y confiable.
• • Validación basada en resultados: El uso del Patrón de Resultado hizo explícitos los resultados. Las pruebas podían verificar transformaciones exitosas, éxitos parciales con advertencias, y errores de validación de negocio. Esto eliminó la ambigüedad y redujo la dependencia de efectos secundarios o logs.
• • Confianza en el cambio: Debido a que la lógica de negocio estaba aislada, era determinista y estaba cubierta por pruebas enfocadas, el sistema podía evolucionar de forma segura, incluso cuando las reglas de negocio cambiaban frecuentemente.

Resultados

La arquitectura logró un fuerte desacoplamiento entre la lógica de negocio y las plataformas de e-commerce, independencia completa del framework a nivel de dominio, alta capacidad de prueba que permite refactorización con confianza, y una arquitectura escalable adecuada para el crecimiento multicanal. El sistema podía evolucionar de forma segura a medida que las reglas de negocio cambiaban, con las pruebas proporcionando retroalimentación inmediata sobre la corrección.