En esta página
Dos empresas clientes tienen un campo llamado «activo». Para una, significa que el consumidor ha comprado algo durante el último año. Para la otra, que el contrato del servicio está vigente. Un conector compartido puede transferir correctamente ambos campos. Una regla común que los trate como el mismo estado de negocio puede ser incorrecta para uno de ellos. Es un ejemplo ilustrativo, no un informe de un despliegue.
Una conversación sobre plataformas compartidas y despliegue local describe a una empresa que reutilizaba gran parte de su infraestructura y aun así realizaba un trabajo considerable dentro del entorno de cada cliente. Sus porcentajes son específicos de esa empresa. La pregunta arquitectónica general es dónde terminan los mecanismos compartidos y empieza el significado local.
Separa el contrato de transporte del contrato de negocio
Un contrato de transporte puede establecer cómo autenticarse en el origen, leer los registros modificados, conservar los identificadores, reintentar de forma segura y exponer los fallos. Estos comportamientos se pueden implementar una sola vez y probar de forma repetida. Son valiosos porque toda integración necesita una ruta fiable para los datos.
Un contrato de negocio define qué registro es la fuente autorizada, qué significa un estado, cuándo se permite una acción y quién puede corregir un error.
- Transporte compartido identidad · reintento · ID de evento
entrega un evento válido
- Política local significado · consentimiento · tiempo
decide si se permite actuar
- Acción autorizada escritura · auditoría
registra el resultado
Ese contrato de negocio depende del flujo de trabajo. Puede usar la misma fuente y el mismo destino que otro cliente y aun así necesitar una respuesta distinta.
Considera una conexión entre una tienda y un sistema de correo electrónico. La plataforma puede ofrecer la recepción de eventos, la deduplicación y un registro de auditoría. Quien lleva el flujo debe definir si «suscrito» significa tener permiso para un propósito concreto de marketing, si una compra suprime un recordatorio de carrito y cómo afecta un cambio de consentimiento a los mensajes que ya están en cola. No son funciones del conector que se puedan deducir de los nombres de los campos.
La asignación ilustrada de Tajo copia directamente tres campos. Fíjate en la decisión que falta: ninguna fila define el permiso de marketing. Reutilizar el transporte ahorra trabajo, pero quien dirige el flujo debe precisar qué estado permite cada acción. Una asignación clara puede mostrar ese vacío sin resolverlo.
Revisa la sincronización antes de ejecutarla
Sincroniza las actualizaciones de clientes con mi plataforma de correo.
Sincronización de clientes
| Campo de origen | Campo de destino | Regla |
|---|---|---|
email | EMAIL | Directa |
first_name | FIRSTNAME | Directa |
last_name | LASTNAME | Directa |
Vista previa sintética superada
3 campos asignados · Sin escrituras en el destino
Diseño ilustrativo basado en las herramientas de asignación de Tajo. Una vista previa sintética y un borrador guardado no activan la sincronización.
| Capa compartida | Capa local |
|---|---|
| Autenticación y renovación de tokens | Qué identidad puede acceder a este flujo |
| Transporte y reintentos de eventos | Qué evento cuenta como transición de negocio |
| Identificadores estables y deduplicación | Qué registros corresponden al mismo cliente real |
| Registro y mecanismos de recuperación | Quién resuelve un estado disputado y cómo |
| Validación del contrato | Qué significan los valores de campo y cuándo pueden activar una acción |
La tabla define un límite de diseño; no afirma que toda implementación se pueda dividir de forma tan nítida.
La reutilización falla cuando oculta desacuerdos
Una plataforma genérica suele añadir un campo de configuración para cada excepción. Al principio parece una forma de conservar la reutilización. Después nadie sabe si un ajuste es una opción técnica, una restricción legal o una decisión de negocio. El núcleo compartido se convierte en un mando a distancia para decisiones de las que no es responsable.
Busca una invariante estable. «No apliques dos veces el mismo evento de origen al mismo registro de destino» puede pertenecer a un motor compartido. «Envía un descuento cuando un cliente pasa a estar activo» no se puede compartir hasta que alguien sea responsable de definir «activo», la audiencia permitida y la política de ofertas. El motor puede ejecutar una política aprobada, pero no debería inventarla.
Esto también facilita el mantenimiento. Si cambia una API, el equipo de la plataforma puede actualizar el adaptador y sus pruebas. Si cambia la definición de cliente apto, quien lleva el negocio puede actualizar la política y los casos de prueba sin esperar a una reescritura del transporte. Un límite claro lleva cada cambio a la persona autorizada para decidirlo.
Reutiliza los mecanismos sin aplanar el significado
Algunas reglas locales sí añaden costes. Sin contratos reutilizables, una plataforma se convierte en una colección de scripts a medida. La solución consiste en identificar mecanismos repetidos antes de abstraer significados que solo parecen iguales. Una primitiva compartida bien diseñada podría aceptar un predicado tipado, la hora del evento y un límite de acción, pero dejar local la definición de negocio del predicado.
El límite se debe comprobar con casos reales. Toma un evento normal, uno duplicado, una corrección tardía y un permiso revocado. Pregunta qué capa es responsable de cada respuesta. Si no se puede asignar un fallo, la abstracción oculta la responsabilidad. Si un cliente nuevo obliga a dar varias interpretaciones distintas a una categoría «activo» compartida, el tipo común es demasiado amplio.
El artículo complementario sobre el despliegue examina si una capacidad funciona dentro de un flujo de trabajo activo. Este pregunta qué se puede construir una vez sin borrar el significado del flujo.
La interfaz entre capas debe ser lo bastante explícita como para rechazar un supuesto erróneo. Un motor compartido puede exigir un ID de evento, la hora de origen, la identidad responsable y el propósito declarado antes de aceptar una solicitud de acción. El flujo local puede aportar la política que decide si esa acción se permite. Si falta el propósito, el motor debe rechazar la solicitud; si la política es ambigua, quien lleva el negocio debe resolverla. Así se puede reutilizar código sin ceder la autoridad sobre el negocio. Documenta el contrato con un ejemplo aceptado y otro rechazado, y prueba ambos cada vez que cambie cualquiera de las capas.
Un conector reutilizable debe facilitar la expresión del significado local y hacer más segura su ejecución. Nunca debe presentar dos promesas distintas como si fueran iguales solo porque sus campos tienen el mismo nombre.
Preguntas frecuentes
¿Qué debería reutilizar normalmente una plataforma de integración?
Se pueden compartir mecanismos estables, como los patrones de autenticación, el transporte, la idempotencia, los reintentos, el registro y las comprobaciones contractuales, cuando los requisitos subyacentes coinciden.
¿Qué debería seguir siendo específico de cada negocio?
El significado de los campos, la autoridad de origen, las reglas de consentimiento, los requisitos de tiempo y quién puede actuar a partir de un estado deben definirse para ese negocio y flujo de trabajo.
¿Cómo pueden comprobar los equipos ese límite?
Intenta expresar un flujo nuevo con primitivas existentes. Si hacerlo cambia el significado del negocio u oculta excepciones en una configuración genérica, conserva esa lógica en el ámbito local y haz explícita la interfaz.