Forma del sistema

Contrato frontend compartido: formas de datos, errores y ownership (quién cambia schema vs quién consume UI).

Commerce contract: catalog, cart, checkout y borde de pagos—distinto de la composición de contenido genérica.

Flujo: request del host → adapter normaliza al contrato correcto → la UI renderiza el contrato, no la API cruda del CMS.

Host CMS / commerce → adapter → contrato content o commerce → UI

Decisiones

Contrato frontend estable vs shapes del CMS en la UI

Elegimos: un contrato estable en el que la UI de features pudiera confiar. Rechazamos: que cada CMS empujara su shape nativo directo a los componentes. Por qué: las features cross-surface dejan de reescribirse cada vez que cambia el backend.

Ownership explícito vs “quien toque, cambia”

Elegimos: límites claros schema team vs UI team, con aviso a consumidores ante cambios de schema. Rechazamos: ediciones de schema sin documentar que sorprenden a la UI. Por qué: un contrato sin dueño es papel mojado; el drift silencioso rompe el borde que acabas de construir.

Viñetas de integración

Estos son patterns across hosts, no cuatro casos de estudio completos.

Borde commerce — Shopify + pagos

Trabajo de smart cart y checkout edge, incluida una form de Stripe adaptada a la UI del producto. Las preocupaciones de commerce (catalog/cart/checkout/pagos) vivían detrás del commerce contract para que detalle de pago y carrito no se esparciera por cada componente presentacional.

Composición CMS — Sanity

Composición de pages con componentes reutilizables en superficies Sanity. Los editores ganaban bloques modulares; el frontend consumía la estructura compuesta por el lado content del contrato en lugar de cablear cada document type a mano.

Boundary de módulos — Drupal

Módulos Drupal nuevos o evolucionados tratados como capacidades con boundary. Esos límites se mapeaban a responsabilidades de adapter para que las APIs específicas de Drupal no se convirtieran en la interfaz pública de la UI de features.

Superficie marketing — HubSpot

En HubSpot CMS hubo trabajo de superficie y UI fixes. Cuando el cambio era solo presentacional, no inventamos ceremonia de contrato; cuando la superficie alimentaba experiencias frontend compartidas, seguía la regla de “el CMS se queda en el borde”.

Qué rechazamos

• Cambios de schema sin dueño o sin avisar al consumidor UI
• Shapes y APIs del CMS filtrándose a componentes de feature

Cuándo no encaja este modelo

Omite la ceremonia completa de contrato + adapter cuando:

• Hay un solo CMS sin reuso cross-surface—el contrato es overhead
• El trabajo es un spike corto sin intención de reusar el borde
• El CMS es el producto (admin UI nativa) y no hay frontend propio que proteger
• El cambio es solo polish de UI sin cambio de contrato

Lección transferible

Mantén un contrato frontend estable—y ownership claro schema vs UI—para que Sanity, HubSpot, Drupal y Shopify se queden en el borde del adapter; separa un commerce contract cuando entren catalog, cart, checkout o pagos (p. ej. Stripe). Omite la ceremonia en CMS one-off, spikes, admin nativo o solo polish de UI.

Más corto: el CMS es el borde; el contrato (con dueño) protege a la UI—y el dinero merece su propio contrato.

Límites de este texto

Anonimizado entre clientes y hosts. Sin schemas propietarios, endpoints internos, credenciales de pago, screenshots de producto ni marcas de clientes. El detalle de layering de forms vive en el caso schema-driven; este caso se queda en contratos multi-host y commerce edge. Trabajo de cliente bajo NDA — se muestra la arquitectura y las decisiones, los detalles de producto quedan fuera por diseño.