Arquitectura por épica · Piezas, datos, eventos y reglas

Actualizado el 18-oct-2026. Primera versión.

Qué responde. Con qué piezas se arma cada épica: los módulos y lo que los rodea, las colecciones de la base única con su dueño, los tópicos de eventos y las reglas de las APIs.

Para quién. Quien diseña o construye una épica.

Estado. [Propuesta] del TL del Nuevo PIM, 18-oct-2026, construida sobre ADR-12. La spec de cada épica dice el qué; estas páginas, el cómo.

Fuente. docs/arquitectura/por-epica/base/.

En 30 segundos

15 módulos en un solo backend; MS-11 a MS-15 son nuevos (ADR-12) y su número es provisional.
67 colecciones en la base pim, cada una con un solo dueño.
16 tópicos: cada uno lo publica un solo módulo, desde su outbox.
Una sola API: los módulos publican /api/v2 (la llaman el BFF, el gateway y el agente), /internal/<módulo> entre módulos, /bff/v1 para las pantallas y /partner/v1 para terceros. No hay capa de compatibilidad.

1. Las piezas

🟩 Verde: nuevo, se construye · 🟦 Azul: ya existe y se queda, se reutiliza su código · 🟧 Naranja: temporal o se retira (se apaga en R3) · ⬜ Gris: sistema externo · ★ en cada épica, su módulo dueño

Pieza	Nombre	Estado	Qué hace
P-PROVEEDOR	Proveedor	—	Da de alta y corrige las propuestas de sus productos en Mercaderías.
P-SELLER	Seller	—	Da de alta sus productos y ofertas en Marketplace.
P-COMPRAS	Compras	—	Da el visto bueno a las propuestas de Mercaderías.
P-GOBIERNO	Gobierno de Datos	—	Corrige datos maestros y resuelve lo que SAP o la IA no pudieron.
P-ADMIN	Administración del catálogo	—	Configura plantillas, atributos, listas, reglas y categorías (Gobierno de Producto).
P-QA	QA y Category	—	Revisa la calidad y la categoría web cuando la IA no alcanza el umbral.
P-ESTUDIO	Estudio fotográfico	—	Logística, fotografía, edición y captura de las muestras físicas.
P-AREAS	Áreas con sección	—	Legal, Sostenibilidad, VAS, Logística y E-commerce: llenan o validan su sección de la ficha.
P-REPOBLAMIENTO	Repoblamiento	—	Corrige productos ya publicados y los vuelve a mandar.
F-PORTAL	Entrada Única · Vendor Center	⟦existe	Blue⟧	El portal de catalogación de hoy, que se queda: las pantallas de catalogación, incluido el módulo M6 de Foro (enriquecimiento, desde R2). Deja de tener backend propio y llega a los módulos por el BFF del portal.
F-FORO	Foro · portal del estudio	⟦existe	Blue⟧	El portal de Foro Fotográfico de hoy, que se queda para la operación física del estudio (muestras, logística, toma). Deja de tener backend propio y llega a los módulos por el mismo BFF del portal.
F-AGENTE	Agente del estudio	—	Programa local junto a la cámara: sube cada foto directo a Activos digitales con credencial de equipo, sin pasar por el BFF.
S-PROVEEDORES	Sistemas de proveedores y sellers	—	Mandan sus productos por API, a través del gateway de terceros.
B-INGRESS	Entrada del clúster	—	Infraestructura con tres puertas: el BFF del portal, el agente del estudio hacia Activos y el gateway de terceros. Pone los límites por puerta.
B-BFF	BFF del portal	⟦nuevo	Green⟧	Un solo BFF para Vendor Center y el portal del estudio: valida el token, aplica los permisos de pantalla y compone pantallas. Sin base de datos y sin reglas de negocio; los servicios no se exponen a internet.
B-GATEWAY	Gateway de terceros /partner/v1	⟦nuevo	Green⟧	Atiende a los sistemas de proveedores y sellers: credenciales de cliente, límite de llamadas y contrato versionado.
MS-01	Catálogo	⟦existe	Blue⟧	Dueño de plantillas, atributos, listas de valores, reglas de captura, categorías web, sitios y diccionarios.
MS-02	Producto	⟦nuevo	Green⟧	Dueño de propuestas, productos, variantes, EAN, cargas masivas, el motor de estados con sus tareas y los trabajos de publicación.
MS-04	Reportes	⟦nuevo	Green⟧	Exportaciones, herramientas y tableros.
MS-05	Auditoría	⟦nuevo	Green⟧	La bitácora: quién cambió qué, con el antes y el después.
MS-06	Evaluación	⟦nuevo	Green⟧	Lista negra, coincidencias y calificación (score) con sus umbrales.
MS-11	Activos digitales	⟦nuevo	Green⟧	Cada archivo una sola vez: carga, validación técnica, nombre, URL de trabajo y copia congelada; cargas masivas de imágenes.
MS-12	Estudio fotográfico	⟦nuevo	Green⟧	Muestras, contenedores, cajas, tarimas, toma, edición, guía de fotos y capacidad del estudio.
MS-13	Identidad y acceso	⟦nuevo	Green⟧	Un solo directorio: usuarios, perfiles, roles, permisos por módulo, acción, negocio y grupo de atributos, y el registro de terceros que llaman por API.
MS-14	Avisos y ayuda	⟦nuevo	Green⟧	Notificaciones en pantalla, correo, avisos al proveedor o seller y centro de ayuda.
MS-15	IA y enriquecimiento	⟦nuevo	Green⟧	Un solo motor de IA: sugerencia de plantilla y de categoría, prellenado, enriquecimiento de atributos y validación de calidad.
MS-07	Ingesta de archivos	⟦nuevo	Green⟧	Recibe los archivos de SAP (122, 141, 142 y las demás interfaces) y la respuesta de o9, y los entrega al módulo dueño.
MS-08	Adaptadores de salida	⟦nuevo	Green⟧	Arma lo que recibe cada destino (4 TXT a SAP, mensajes en los tópicos que lee la tienda, XML a OMS, Marketplace y Señalización, archivo de placeholders a o9) y devuelve el acuse.
MS-09	Publicador de categorías	⟦existe	Blue⟧	Único que publica el árbol de categorías a la tienda.
MS-10	Exportador al DWH	⟦nuevo	Green⟧	Manda al DWH el producto y el diccionario de plantillas.
MS-03	Migración y convivencia	⟦temporal	Yellow⟧	Carga desde P360 y mantiene la convivencia hasta R3; después se apaga.
D-BASE	Base pim	—	Una sola base. Cada colección tiene un solo módulo dueño.
D-EVENTOS	Eventos	—	Los tópicos por los que cada módulo avisa sus cambios desde su outbox.
D-ARCHIVOS	Archivos e imágenes (almacén y CDN)	—	Los binarios: la ficha sólo guarda su URL.
X-SAP	SAP	⟦externo	Grey⟧	Crea los artículos y manda datos maestros, precios y costos.
X-TIENDA	Tienda en línea	⟦externo	Grey⟧	Product Data Service y commercetools: reciben producto y categorías.
X-OMS	OMS	⟦externo	Grey⟧	Recibe el producto para surtir pedidos.
X-MARKETPLACE	Marketplace	⟦externo	Grey⟧	El portal de ofertas de los sellers (Mirakl, hasta que lo reemplace Vendor Center).
X-SENALIZACION	Señalización	⟦externo	Grey⟧	Recibe el producto para las etiquetas y la señalización en tienda.
X-DWH	DWH	⟦externo	Grey⟧	El almacén de datos para análisis.
X-O9	o9 (planeación de compras)	⟦externo	Grey⟧	Recibe los placeholders de pre-compra y devuelve cuáles recomienda comprar, por archivo en un bucket.
X-P360	P360	⟦temporal	Yellow⟧	El PIM de hoy: fuente de la migración y de la convivencia, hasta que se apague.
X-MODELOS	Modelos de IA	⟦externo	Grey⟧	Los modelos que usa el módulo de IA, incluida la predicción de grupo de artículo que ya corre.
X-CORREO	Servicio de correo	⟦externo	Grey⟧	Manda los correos a proveedores, sellers y usuarios internos.
X-IDP	Proveedor de identidad	⟦externo	Grey⟧	Inicio de sesión y emisión del token.
X-EU-FORO	Backends de hoy de Entrada Única y Foro	⟦temporal	Yellow⟧	Los backends y bases de hoy de los dos portales, mientras convivan: leen los avisos idmc_*, Entrada Única responde GET /users/auth (el BFF toma de ahí el contexto del usuario hasta R2) y Foro tiene su servicio de usuarios. Se apagan con tráfico cero en R3; los portales se quedan.
X-WEB	Sitios web públicos	⟦externo	Grey⟧	Las páginas públicas de producto de sellers, marcas y competencia. Sólo MS-15 las lee (scraping); no reciben nada del PIM.

2. Las colecciones y su dueño

Colección	Dueño	Qué guarda
`attributes`	MS-01	Cada atributo: tipo, lista, restricciones, grupos e identificadores externos.
`attribute_groups`	MS-01	Grupos de atributos, incluidos los de permiso (quién ve y quién edita).
`lovs`	MS-01	Cabecera de cada lista de valores.
`lov_values`	MS-01	Cada valor de lista: código, etiqueta, orden y equivalencias por sistema.
`taxonomies`	MS-01	Los árboles: plantillas, grupos de artículo y sitios web.
`taxonomy_nodes`	MS-01	Plantillas y nodos de grupo de artículo, con la configuración de atributos de cada plantilla.
`template_views`	MS-01	La vista efectiva ya resuelta por plantilla y negocio: qué atributos pide y cuáles son obligatorios.
`governance_rules`	MS-01	Reglas de captura y clasificación: marcas por plantilla, grupo de artículo a plantilla, alcance del proveedor y lista negra de Marketplace.
`reference_table_defs`	MS-01	Definición de cada diccionario.
`reference_tables`	MS-01	Las entradas de los diccionarios: tallas, colores, impuestos, excepciones y demás datos de referencia.
`categories`	MS-01	Cada categoría web con su lugar en el árbol y su estado.
`brands`	MS-01	Los sitios (banners): Liverpool, Suburbia y los demás.
`id_sequences`	MS-01	El siguiente identificador de plantillas y catálogos.
`import_jobs`	MS-01	Cargas masivas de configuración del catálogo, con revisión previa y resultado por fila.
`governance_receipts`	MS-01	El recibo de cada escritura confirmada en el catálogo (antes operation_receipts).
`governance_outbox`	MS-01	Los cambios del catálogo que esperan salir como evento (antes outbox).
`products`	MS-02	La familia del producto con sus variantes, valores, imágenes (URL), clasificaciones, estado, tareas abiertas y rechazos.
`product_drafts`	MS-02	Borradores del alta guiada.
`identifier_registry`	MS-02	Unicidad de SKU y de EAN por negocio.
`product_groups`	MS-02	Looks, configurables y venta cruzada.
`product_versions`	MS-02	Foto numerada del producto en cada versión.
`product_sequences`	MS-02	El siguiente bloque de identificadores de producto.
`tasks`	MS-02	Todo el trabajo asignado: visto bueno, corrección, Gobierno de Datos, foto, secciones, QA, revisión del cambio y repoblamiento.
`product_jobs`	MS-02	Trabajos asíncronos: cargas masivas de productos, edición masiva y publicación.
`product_delivery_status`	MS-02	El estado de publicación por producto y canal: Pendiente, Enviado, Publicado, Error o Retirado.
`publication_rules`	MS-02	El mínimo que pide cada canal para publicar.
`catalog_exceptions`	MS-02	Excepciones de catalogación: qué no se publica o va por la vía rápida.
`product_reference_tables`	MS-02	Configuración del motor de estados y del matching: transiciones, estados externos y pesos.
`product_receipts`	MS-02	El recibo de cada escritura confirmada en el producto (antes operation_receipts).
`product_outbox`	MS-02	Los cambios del producto que esperan salir como evento (antes outbox).
`validation_thresholds`	MS-06	Los umbrales de coincidencia y de calificación por negocio.
`validation_results`	MS-06	El resultado de cada evaluación: lista negra, coincidencias con su confianza y score.
`asset_types`	MS-11	Los tipos de activo (principal, detalle, isométrica, video, certificado…) con su ficha técnica: medidas, peso, formato, máximo y si se publica.
`assets`	MS-11	Cada archivo una vez: a qué producto, variante y posición pertenece, su validación técnica, URL de trabajo y URL congelada.
`asset_jobs`	MS-11	Cargas masivas de imágenes, por archivo comprimido, carpeta o lista de URL.
`asset_outbox`	MS-11	Los cambios de activos que esperan salir como evento.
`studio_samples`	MS-12	Cada muestra física que entra al estudio, por SKU, con su recorrido.
`studio_logistics`	MS-12	Contenedores, cajas, tarimas, tiendas y salidas con vale.
`studio_work`	MS-12	Tomas, ediciones y capturas por SKU, con quién las tiene asignadas.
`studio_config`	MS-12	Guía de fotos, capacidad por fotógrafo, tiempos y configuración de la edición con IA.
`studio_outbox`	MS-12	Los cambios del estudio que esperan salir como evento.
`users`	MS-13	Cada usuario interno, proveedor o seller, su liga con el proveedor de identidad y sus roles.
`roles`	MS-13	Perfiles y roles, con sus membresías y su alcance (negocio, sección, proveedor o seller, vigencia). Los permisos de dominio los decide el servicio dueño con estos roles (decisión 19).
`partners`	MS-13	El registro de terceros: proveedores y sellers que llaman por API, con su tipo, negocios, tiendas, alcances, límites y clientes (catalogación por API §3.1).
`identity_outbox`	MS-13	Los cambios de identidad que esperan salir como evento.
`notifications`	MS-14	Cada aviso a un usuario, proveedor o seller: canal, texto, si ya lo leyó.
`help_articles`	MS-14	El contenido del centro de ayuda.
`ai_jobs`	MS-15	Cada trabajo de IA con su entrada, su resultado y su confianza.
`ai_config`	MS-15	Qué modelo atiende cada tarea y con qué umbral.
`dashboard_profiles`	MS-04	Los tableros personales de cada usuario.
`dashboard_results`	MS-04	El último resultado de cada tarjeta.
`report_jobs`	MS-04	Exportaciones y reportes asíncronos.
`audit_events`	MS-05	Quién cambió qué, cuándo, desde dónde, con el antes y el después.
`sap_inbound_files`	MS-07	Cada archivo que llega de SAP y el avance de sus registros.
`category_delivery_status`	MS-09	El último envío de cada categoría a la tienda.
`mig_runs`	MS-03	Cada corrida de migración con sus conteos.
`mig_issues`	MS-03	Lo que no se pudo migrar y por qué.
`mig_reconciliation`	MS-03	Las diferencias entre P360 y el Nuevo PIM durante la convivencia.
`egress_batches`	MS-08	Cada lote que sale a un destino: productos y versiones, intentos, respuesta del destino, huella de lo enviado y, si quedó incierto, la decisión de una persona con su motivo.
`mig_id_map`	MS-03	El mapa de identidad entre sistemas: cada ID heredado de P360, Omega o Entrada Única con su llave en el Nuevo PIM y cómo se resolvió, y los bloques de Identifier reservados en la secuencia de P360.
`mig_p360_writes`	MS-03	Cada escritura que MS-03 hace en P360 por encargo de MS-01 o MS-02 mientras P360 es la fuente: el cambio, su llave de idempotencia, la respuesta de P360 y la versión recargada. Se borra 30 días después y se apaga con P360.
`governance_change_requests`	MS-01	Cada solicitud de cambio del catálogo: qué objetos toca, el antes y el después por campo, el canal (pantalla, carga, API, IA o migración), quién la pidió y quién la decidió, su estado (pendiente, aprobada, rechazada, aplicada, en conflicto o vencida) y su recibo.
`saved_searches`	MS-02	Búsquedas de productos guardadas por usuario, con su nombre, sus filtros y con qué áreas se comparten.
`report_findings`	MS-04	Los hallazgos de las corridas de consistencia y de visibilidad: objeto, caso, valor en cada sistema, negocio, oferta activa, causa, fecha de corte, estado y tarea que lo atiende.
`report_monitors`	MS-04	Los casos de consistencia y las alertas que vigila Reportes: umbral, línea base, horario, a quién se avisa, si abren tarea y cuándo se cierran.
`report_facts`	MS-04	Los hechos que Reportes arma con los eventos de los demás módulos: entrada, salida y visitas de cada paso; errores por punto de detección; tiempo de Aprobado a Publicado por canal; latencia de calculados; uso de la API de terceros por minuto y conteos diarios de visibles. No es fuente de ningún dato de operación.
`identity_receipts`	MS-13	Los planes de identidad por confirmar (vencen a los 10 minutos) y el recibo de cada cambio confirmado de usuarios, roles y terceros, con lo que respondió el proveedor de identidad.

3. Los eventos

Cada módulo guarda y, en la misma transacción, deja el evento en su outbox; de ahí sale al tópico. La entrega es al menos una vez: quien consume ignora el eventId repetido y la versión vieja.

Tópico	Lo publica	Para qué	Tipos
`catalog.governance.changed`	MS-01	Avisar que cambió la configuración del catálogo.	ATTRIBUTE_CHANGED, LOV_CHANGED, LOV_VALUE_CHANGED, TEMPLATE_CHANGED, TEMPLATE_VIEW_CHANGED, REFERENCE_TABLE_CHANGED, RULE_CHANGED, TAXONOMY_NODE_CHANGED, CATEGORY_UPSERTED, CATEGORY_MOVED, CATEGORY_UNLINKED, CATEGORY_REPUBLISH_REQUESTED, ATTRIBUTE_GROUP_CHANGED
`catalog.product.changed`	MS-02	Avisar que cambió un producto, su estado o sus tareas.	PRODUCT_CREATED, PRODUCT_UPDATED, PRODUCT_DELETED, VARIANT_LINKED, VARIANT_UNLINKED, CLASSIFICATION_CHANGED, MEDIA_CHANGED, STATUS_CHANGED, STATUS_CORRECTED, SKU_ASSIGNED, EAN_CHANGED, REJECTION_ADDED, TASK_CHANGED, OFFER_CREATED, CONFIG_CHANGED
`catalog.product.publication`	MS-02	Pedir que un producto salga a sus canales, a SAP o a o9.	PUBLICATION_REQUESTED, SAP_CREATION_REQUESTED, PLANNING_EXPORT_REQUESTED
`catalog.delivery.result`	MS-08	Devolver el acuse de cada destino.	DELIVERY_RESULT, EXTRACTION_READY
`catalog.sap.inbound`	MS-07	Avisar lo que llegó de SAP.	SAP_ARTICLE_CREATED, SAP_ARTICLE_FAILED, SAP_MASTER_DATA_CHANGED
`catalog.egress.files`	D-ARCHIVOS	El almacén avisa que llegó un archivo nuevo de SAP.	OBJECT_FINALIZE
`catalog.asset.changed`	MS-11	Avisar que un archivo se subió, se validó, se rechazó o se congeló.	ASSET_UPLOADED, ASSET_VALIDATED, ASSET_REJECTED, ASSET_FROZEN, ASSET_DELETED, ASSET_JOB_FINISHED
`catalog.studio.changed`	MS-12	Avisar el avance de una muestra en el estudio.	SAMPLE_RECEIVED, SHOT_COMPLETED, EDITION_COMPLETED, CAPTURE_COMPLETED, SAMPLE_RETURNED
`catalog.identity.changed`	MS-13	Avisar altas, bajas y cambios de permisos.	USER_CHANGED, ROLE_CHANGED, PARTNER_CHANGED
`catalog.ai.result`	MS-15	Entregar un resultado de IA que tardó (lotes y cargas masivas).	AI_SUGGESTION_READY, AI_ENRICHMENT_READY, AI_QUALITY_READY
`catalog.validation.result`	MS-06	Entregar la evaluación de una carga masiva, renglón por renglón.	EVALUATION_DONE
`idmc_post_products`	MS-02 (temporal)	Convivencia: lo que hoy reciben los backends de los fronts mientras se apagan.	(contrato de hoy)
`idmc_put_products`	MS-02 (temporal)	Convivencia: cambios de producto con el contrato de hoy.	(contrato de hoy)
`idmc_put_template`	MS-01 (temporal)	Convivencia: cambios de plantilla con el contrato de hoy.	(contrato de hoy)
`idmc_put_value-list-relation`	MS-01 (temporal)	Convivencia: listas de valores con el contrato de hoy.	(contrato de hoy)
`idmc_post_look`	MS-02 (temporal)	Convivencia: looks con el contrato de hoy.	(contrato de hoy)

4. Las reglas de las APIs

Escribir es en dos pasos. POST …/plans revisa y dice qué va a pasar sin escribir (es la validación en el momento); POST /api/v2/<módulo>-plans/{planId}/apply confirma y deja un recibo.
Cabeceras: Authorization y X-Request-Id siempre; Idempotency-Key en toda escritura; If-Match con la versión al cambiar algo que tiene versión.
Respuesta: {"success": true, "data": …}; los errores traen un código con nombre (VALIDATION_ERROR, VERSION_CONFLICT, PLAN_EXPIRED…), el detalle por campo y un correlationId.
Lo que tarda responde 202 con un recibo y avisa con un evento.
Tres puertas: el BFF del portal para las pantallas, el agente del estudio directo a Activos y el gateway de terceros. El BFF valida el token, aplica los permisos de pantalla y compone; no guarda datos ni decide reglas (decisión 19 del backend compartido).
Seguridad: el token se valida en la puerta y otra vez en cada módulo, que decide sus permisos de dominio con los roles de MS-13 (ADR-05). Los terceros usan credenciales de cliente registradas en MS-13.
Sin capa de compatibilidad (decisión 20): las rutas de hoy no se reconstruyen; sólo queda DELETE /productmanagement/proposals/upc-eans para el middleware de P360, hasta R3.

Fuentes

[D] docs/arquitectura/por-epica/base/modulos.json, colecciones.json y eventos.json.
[D] docs/arquitectura/omega-a-pim-headless/contratos-api.md §1 y §3, y datos/.
[D] ADR-12 y ADR-05.