- Para quién es: Arquitectos e ingeniería senior en productos greenfield o salidas de CMS con plugins, donde marketing y compliance necesitan velocidad a la vez.
- Qué problema resuelve: Cuando ediciones de experiencia y cambios de pago/auditoría comparten una superficie desplegable, cada titular puede tocar webhooks de Stripe, identidad o evidencia LGPD/GDPR.
- Qué cambia si aplicas esto: Tres planos (experiencia / transacción / registro) con caminos de integración que no se solapan — un publish en CMS no redespliega lógica de matrícula; BFF + RLS para que el plano experiencia no pueda invocar primitivas de transacción; ADRs que sobreviven rotación de equipo.
La mayoría de discusiones de arquitectura empiezan con una encuesta de frameworks: monolito o microservicios, WordPress o Next.js, build o buy. Esa es la primera pregunta equivocada.
La primera pregunta correcta es organizacional y técnica a la vez: ¿qué cambios deben poder hacer personas no técnicas sin pedirle a ingeniería, y qué cambios debe poder demostrar ingeniería en una auditoría? Cuando esos dos conjuntos se solapan en una sola unidad desplegable, no tienes "un stack" — tienes un cuello de botella disfrazado de plataforma.
Abajo va arquitectura desacoplada por ownership: partir sistemas para que marketing, educación y operaciones publiquen con autonomía mientras ingeniería conserva dinero, identidad y contratos de datos. aurin.mx (opens in new tab) y la propuesta pública ATFX Educacao (opens in new tab) ilustran el patrón; los modelos valen sin depender de esos nombres.
Los conceptos citan material publicado: Ley de Conway (opens in new tab), Team Topologies (opens in new tab), Architecture Decision Records (opens in new tab), Backends for Frontends (opens in new tab), defense in depth (opens in new tab) y ley de protección de datos (GDPR Art. 20 (opens in new tab), LGPD Art. 18 (opens in new tab)). Los casos provienen de aurin.mx (opens in new tab) y la propuesta pública ATFX Educacao (opens in new tab).
Desacoplar no es lo mismo que "más servicios"
> En pocas palabras: Más microservicios no es automáticamente más libertad — el objetivo es menos efectos secundarios sorpresa. En literatura de ingeniería, desacoplar significa reducir la amplificación del cambio: una modificación en un área no debería forzar redespliegues, migraciones ni reescrituras de compliance en áreas no relacionadas.
Eso es distinto de:
- Distribución — más procesos o vendors (que pueden aumentar acoplamiento operativo: red, versionado, observabilidad).
- Abstracción por moda — interfaces sin dueño que quedan obsoletas la semana del lanzamiento.
El resumen de Conway's Law por Martin Fowler (opens in new tab) es la base: las organizaciones producen diseños que reflejan cómo se comunican. Si marketing e ingeniería deben coordinar cada titular, terminarás con un sistema donde cambiar titulares requiere ingeniería — sin importar cómo etiquetes el diagrama.
El objetivo de diseño es reflejo intencional: alinear límites de equipo y límites de software, con la maniobra inversa de Conway (opens in new tab) (diseñar el sistema que quieres que la organización se convierta).
El modelo de ownership: tres planos
> En pocas palabras: Tres zonas: lo que edita marketing, lo que toca dinero, lo que importa a legal — separadas a propósito. Una forma práctica de enseñarlo en revisiones de arquitectura es nombrar tres planos. Cada plano tiene un dueño principal y un contrato de integración.
| Plano | Dueño no técnico típico | Ingeniería debe poseer |
|---|---|---|
| Experiencia | Copy, layout, campañas, estructura de cursos en CMS | Límites de auth, rutas API, flags con auditoría |
| Transacción | (casi nadie — finanzas observa dashboards) | Precios, pagos, derechos, idempotencia, webhooks |
| Registro | Legal/privacidad define políticas; DPO el proceso | Schema, residencia, APIs export/delete, audit logs |
El ownership no técnico es creíble solo cuando quienes están en experiencia no pueden invocar primitivas de transacción o registro desde su herramienta — no porque se lo pidieron amablemente, sino porque el camino de integración no existe.
Confiar solo en capacitación falla a escala. La guía de autorización OWASP (opens in new tab) aplica a roles internos: aplicar en servidor y base, no en disciplina de UI.
Contrato de superficie (el artefacto que debe producir arquitectura)
Antes de elegir vendors, escribe un contrato de superficie de una página por rol:
Así los ADR se vuelven operativos. El formato de Architecture Decision Records de Michael Nygard (opens in new tab) (contexto, decisión, consecuencias) existe para estos trade-offs — no para registrar que elegiste React.
Team Topologies aplicado a límites de software
> En pocas palabras: Cómo organigrama y diagrama deberían rimar para que los equipos no se pisen. Team Topologies (opens in new tab) (Skelton & Pais) define cuatro tipos de equipo. No necesitas el libro para el mapeo:
| Tipo | Software con el que debe alinearse | Anti-patrón |
|---|---|---|
| Stream-aligned | Journey estudiante/comprador en la app producto | Un equipo por capa (solo frontend, solo DB) |
| Platform | Auth, pagos, observabilidad, APIs de export compartidas | Cada producto reimplementando webhooks Stripe |
| Enabling | Ayuda temporal para salir de WordPress/plugins | Dependencia permanente de consultores |
| Complicated-subsystem | Pipeline de video, fraude, impuestos | Ocultar complejidad en un plugin CMS |
Cuando un área no técnica necesita autonomía, sueles crear una experiencia stream-aligned para ellos (su CMS, su Webflow) conectada a un núcleo platform por APIs estrechas — no darles SSH a producción.
Patrones que implementan desacoplamiento por ownership
> En pocas palabras: Patrones concretos (CMS headless, capa API, seguridad por fila) en lenguaje de negocio.
1. Backends for Frontends (BFF)
El patrón BFF (opens in new tab) pone cada tipo de cliente detrás de una API server-side adaptada a ese cliente. El navegador de marketing no debe cargar URLs de webhook n8n, secretos Stripe ni service-role de base de datos.
Ingeniería posee el BFF. Editores poseen el CMS. El contrato entre ambos es un conjunto pequeño de endpoints documentados — a menudo lectura para marketing, escritura solo dentro de la app producto.
2. CMS headless como plano de experiencia
Un CMS headless (opens in new tab) separa estructura de contenido de código de entrega. Editores trabajan en admin; la app consume contenido en build o request.
Regla arquitectónica crítica: el CMS no es la fuente de verdad del dinero ni de la identidad. Si los enrollments viven en tablas que editores pueden consultar, colapsaste planos.
3. Política en la capa de datos (RLS y más)
Los checks en aplicación son necesarios pero no suficientes. Row Level Security en PostgreSQL (opens in new tab) aplica límites aunque un bug salga a producción o filtre una key de solo lectura.
Combina RLS con keys de mínimo privilegio: la integración de marketing usa una key anónima o acotada que físicamente no puede SELECT en payments — verificado en CI, no en un wiki.
4. Webhooks como handoff de transacción
Proveedores de pago e identidad (webhooks Stripe (opens in new tab), webhooks Clerk (opens in new tab)) son la forma estándar de pasar de "el usuario pagó" a "nuestra base refleja el derecho".
Requisitos arquitectónicos:
- Verificar firmas en cada webhook entrante (firmas Stripe (opens in new tab)).
- Handlers idempotentes (eventos duplicados no deben enrollar dos veces).
- El plano de experiencia nunca llama webhooks directamente.
5. Credenciales de vida corta para media
Para video o descargas, buckets públicos son fallo de ownership. URLs firmadas en Google Cloud (opens in new tab) atan acceso a una decisión en servidor tras verificar derecho — típicamente minutos.
6. ADR para buy vs build
Al evaluar WordPress + plugins LMS vs núcleo a medida, registra un ADR. La propuesta ATFX Educacao (opens in new tab) es básicamente un pack ADR para stakeholders: alternativas, rechazos con evidencia, checklist compliance, costos.
Rechazar WordPress como núcleo LMS allí apoya hechos que muchos arquitectos reconocen:
1. Composición de plugins — datos de curso, membresía y comercio en schemas incompatibles, subiendo costo de migración y export. 2. Plugins de acceso vs multisite — el soporte multisite de MemberPress no es el modelo principal; arquitecturas que asumen membresía en red pelean con la herramienta. 3. Evidencia de compliance — portabilidad LGPD Art. 18 (opens in new tab) es trivial solo con registro unificado del titular — análogo al Art. 20 GDPR (opens in new tab) en la UE.
WordPress puede ganar el plano de experiencia de una landing — sobre todo si editores ya dominan Elementor — si consume datos públicos del catálogo por integración read-only y no guarda PII de alumnos.
Modos de fallo que el arquitecto debe reconocer
> En pocas palabras: Banderas rojas en reviews — cuando “desacoplado” sigue significando que un equipo bloquea a otro.
| Síntoma | Causa probable | Dirección de arreglo |
|---|---|---|
| "Un cambio de copy rompió checkout" | Planos experiencia y transacción comparten DB o deploy | Separar deploy; BFF + CMS |
| "Cada campaña necesita ingeniería" | Sin superficie de marketing propia | Headless o Webflow + contrato CDN fijo |
| "El export para legal tardó 3 semanas" | Datos fragmentados en plugins | Plano registro unificado + API export |
| "Microservicios pero una sola DB" | Monolito distribuido | Ownership de schema por plano |
| "Solo Alex sabe por qué cayó prod" | Sin ADR ni contratos de superficie | Documentar límites; tests de scope de keys |
Compliance como restricción arquitectónica (no nota legal al pie)
> En pocas palabras: La ley de privacidad define dónde viven los datos — no algo que pegas al final. La ley de privacidad convierte el "debemos ser dueños de los datos" en requisitos verificables.
| Requisito (ejemplos) | Implicación arquitectónica |
|---|---|
| LGPD Art. 18 (opens in new tab) / GDPR Art. 20 (opens in new tab) portabilidad | Vista única del titular + endpoint export machine-readable |
| Residencia de datos | DB y object storage en región fija (regiones Supabase (opens in new tab)) |
| Versionado de consentimiento | audit_log append-only ligado a versión de política |
| PCI en tarjetas | Stripe Elements / Payment Intents (opens in new tab); datos de tarjeta nunca en el CMS |
ANPD (opens in new tab) y supervisores en la UE piden cada vez más cómo demuestras controles — lo que favorece arquitecturas donde la evidencia es una query, no auditoría forense de plugins.
La propuesta ATFX estima USD 25k–40k y 6–8 meses para migrar si se elige mal el LMS al inicio. Es ilustrativo de amplificación del cambio en dominios regulados — no una cifra universal.
Arquitectura de referencia: LMS regulado (desde propuesta)
> En pocas palabras: Ejemplo: educación financiera en Brasil — sitio de marketing separado de matrículas y pagos. Compresión de un split LMS moderno para educación financiera LATAM — útil aunque no trabajes en ATFX.
Secuencia de compra (lógica de negocio en servidor):
Acceso ([defense in depth](https://csrc.nist.gov/glossary/term/defense_in_depth)):
1. Middleware de identidad valida sesión. 2. Middleware de app verifica fila de enrollment. 3. Ruta de media re-verifica y emite URL firmada de vida corta.
Cambiar imagen del hero en marketing no aparece en esa secuencia — por diseño.
Arquitectura de referencia: editorial vs automatización (sitio en producción)
> En pocas palabras: Ejemplo: sitio en vivo donde editores publican copy y la automatización del chat va aparte. En un sitio de servicios aparecen los mismos tres planos con vendors distintos:
- Experiencia: CMS headless alimenta páginas (proyectos, servicios, legales).
- Aplicación: proxy SSR expone
/api/chaty calendario; secretos solo en servidor (endpoints Astro (opens in new tab)). - Automatización: motor de workflows (webhooks n8n (opens in new tab)) posee copy del diálogo y contexto LLM — desacoplado del cadence de publish del CMS.
La lección operativa con side effects por keywords del bot: desacoplar no elimina acoplamiento; documenta dónde vive. Cuando copy del bot y detectores en cliente divergen, el booking falla con HTTP 200 — clase de bug que el arquitecto debe anticipar con contract tests entre planos, no fusionando todo en un solo admin.
Checklist: revision de arquitectura antes de construir
> En pocas palabras: Preguntas para la sala antes de que alguien se comprometa con un stack de proveedores. Úsalo en design reviews sin depender de repos propietarios:
1. Planos — ¿Puedes nombrar dueños de experiencia, transacción y registro en una frase cada uno? 2. Contratos de superficie — ¿Cada rol no técnico tiene lista escrita de puede / no puede? 3. Keys — ¿Cada integración usa la credencial más estrecha que funciona? ¿Quién la rota? 4. Independencia de deploy — ¿Marketing puede publicar con la app congelada por auditoría de pagos? 5. Export — ¿Legal obtiene bundle del titular en una llamada API? ¿Qué tablas quedan fuera y por qué? 6. Disciplina webhook — ¿Verificación de firma, idempotencia, dead-letter visible? 7. Rastro ADR — ¿Alternativas rechazadas con consecuencias (plugin soup, multisite, residencia)? 8. Chequeo Conway — ¿El diagrama exige chat diario entre equipos para trabajo rutinario? (Conway's Law (opens in new tab))
Qué medir después del lanzamiento
> En pocas palabras: Métricas simples que ejecutivos pueden seguir — no solo gráficas de uptime para ingeniería.
| Métrica | Señal sana | Señal de fallo de ownership |
|---|---|---|
| Tiempo mediano de publish de copy sin ingeniería | Horas | Tickets de varios días |
| % cambios de checkout que tocan CMS | Casi cero | Cambio de precio desde page builder |
| Error budget de webhooks | <1% tras retries | Deriva silenciosa de derechos |
| SLA export del titular | Automático en minutos | SQL manual por pedido |
| Páginas on-call por deploy de marketing | Raras | Cada campaña |
Referencias (externas — lectura núcleo)
> En pocas palabras: Lectura base si quieres profundizar con tu equipo de arquitectura.
Cierre
> En pocas palabras: Elige límites por quién debe cambiar qué — los frameworks van después. Arquitectura desacoplada para ingeniería no es maximizar cajas en un diagrama. Es minimizar el radio de explosión del trabajo rutinario alineando límites de software con quién realmente posee el cambio — editores, marketers, finanzas, plataforma y compliance.
Los frameworks son intercambiables. El ownership no. Empieza por planos, contratos de superficie y ADR; elige WordPress, Next.js o microservicios solo cuando sepas qué plano puede poseer cada herramienta. Cuando equipos no técnicos publican en su superficie e ingeniería puede demostrar el resto en código y queries, construiste algo enseñable — no una diapositiva de cierre que solo se entiende si la audiencia leyó otros cinco casos antes.