Dos marcas comparten tema, motor y componentes. Cambian el dominio, la identidad visual, parte del catálogo y el equipo que las mantiene. La pregunta de arquitectura es dónde vive lo que se comparte y qué impide que lo propio de una marca se filtre en la otra.
Hay tres respuestas habituales. Una instalación única que aloja varias marcas, un repositorio por marca con un tronco común enlazado, o un único repositorio con una carpeta por marca. La tercera es el patrón de monorepoGlosarioMonorepoRepositorio de control de versiones que aloja varios proyectos, paquetes o sitios en un único árbol de código. Aplicado a WordPress con varias marcas, un monorepo guarda una sola copia del tema, del motor y de los widgets compartidos, y una carpeta por sitio con lo que es propio de cada uno. Evita las copias divergentes de los repositorios clonados y los commits de actualización de puntero de los submódulos de Git.Ver término completo → multi-marca, y funciona solo si el aislamiento que ofrecen las otras dos se sustituye por reglas que una máquina pueda comprobar.
Aislamiento por copia y aislamiento por reglas
Aislar por copia significa que cada marca tiene su propio código. El aislamiento es físico. Un cambio en una marca no puede romper la otra, porque no comparten ni un fichero. El precio llega después. Las correcciones no cruzan, las dos copias divergen en silencio y llega un día en que nadie sabe cuál de las dos tiene el arreglo correcto.
Aislar por reglas significa que existe una sola copia de cada paquete compartido y que un conjunto de convenciones define qué puede variar entre marcas y dónde. El aislamiento es lógico. La divergencia desaparece como categoría de problema, y a cambio un error en el código compartido llega a todas las marcas a la vez.
Cómo se comparan con multisite y con repositorios clonados
MultisiteGlosarioMultisiteModo de WordPress que ejecuta varios sitios sobre una misma instalación, con un único código y una base de datos compartida por la red. Cada sitio de la red puede tener su propio dominio mediante mapeo de dominios. El código, los plugins y el tema se instalan una vez y se activan por sitio o en toda la red. La contrapartida es que los sitios comparten contenedor, base de datos y ciclo de actualizaciones.Ver término completo → comparte la instalación, el proceso y la base de datos de la red. Es la opción más barata de alojar y la que menos aísla. Los repositorios clonados con submódulos de Git aíslan mucho y arrastran un coste de sincronización constante. La tabla resume las diferencias de fondo.
| Criterio | Monorepo multi-marca | Multisite | Repos clonados con submódulos |
|---|---|---|---|
| Copias del código compartido | Una | Una | Una en el submódulo, el resto se clona y diverge |
| Base de datos | Una por sitio | Compartida por la red | Una por sitio |
| Servidores y contenedores | Uno por sitio | Compartidos | Uno por sitio |
| Fallo o actualización del código común | Llega a todas las marcas al desplegar, servidor a servidor | Afecta a toda la red a la vez | Se queda dentro del repositorio |
| Entrega de un cambio común | Un commit | Una actualización de la red | Un commit en el submódulo y uno de puntero por repositorio |
| Administración | Por sitio | Un panel de red | Por sitio |
| Coste de infraestructura | Alto, todo se duplica | Bajo | Alto, todo se duplica |
| Qué sostiene el aislamiento | Reglas y comprobaciones | La propia plataforma | La separación física |
Ninguna columna gana en todas las filas. Multisite compensa si las marcas comparten equipo, ciclo de actualizaciones y nivel de riesgo, porque un único panel y una única base de datos cuestan menos de mantener. Los repositorios clonados compensan si cada marca tiene un equipo y un ritmo propios y el código común es poco. El monorepo compensa cuando el código compartido es la mayor parte del producto y la infraestructura puede duplicarse sin problema.
Las cinco piezas del patrón
El patrón descansa en cinco decisiones que se refuerzan entre sí. Quitar una debilita las demás.
Una opción de marca activa
Una sola opción de configuración declara la marca de cada instalación y un helper del código compartido la lee. Todo lo que cambia entre marcas cuelga de ahí o de un filtro que rellena el paquete del sitio. La hoja de estilos de la marca, los nombres del marcado estructurado y el catálogo que solo existe en una de ellas se resuelven con esa opción. Si una marca necesita un comportamiento propio, el código compartido pregunta por la marca y no se bifurca en un segundo fichero.
Un paquete de sitio
Cada marca aporta un paquete pequeño con lo que le pertenece. Dominio, ruta de acceso, orígenes externos, valores por defecto y la configuración ligada a su contenido. El paquete solo fija valores por defecto. Lo que un administrador guarda en la configuración de la plataforma siempre manda, de modo que el paquete nunca pisa una decisión humana.
Ensamblado por sitio
Un paso de construcción compone el árbol desplegable de cada marca con los paquetes compartidos y el paquete de ese sitio, y retira cualquier paquete de otra marca que hubiera quedado. Cada servidor carga un único árbol de código. El ensamblado convierte una convención («esto es de la marca B») en un resultado verificable, porque el árbol de la marca A no contiene nada de la B.
Infraestructura independiente por sitio y entorno
Cada marca y cada entorno tienen su propio stack. Contenedores, red, volúmenes, base de datos y variables de entorno no se comparten. Una convención de nombres con el entorno y la marca evita choques cuando dos stacks conviven en una misma máquina. Si algo hace falta en las dos marcas, se copia en las dos carpetas de infraestructura, y esa duplicación deliberada es el precio de que una caída o una mala configuración se queden en su sitio.
Reglas de identificadores por sitio
Los identificadores de entradas, adjuntos, plantillas y tipos de contenido pertenecen a la base de datos de cada marca. Un identificador copiado de una a otra apunta a un registro que no existe o a otro distinto, y el fallo no avisa. Por eso el código compartido no lleva identificadores escritos. Los resuelve en tiempo de ejecución por una opción guardada, por un identificador legible o por una consulta, y cada marca los rellena con los suyos.
Las reglas necesitan comprobaciones
Una regla que solo vive en un documento se incumple en la tercera semana. El patrón exige que cada regla tenga una comprobación que falle de forma visible, y que esa comprobación se ejecute para todas las marcas antes de cada entrega.
Una verificación razonable monta el árbol de cada sitio, revisa la sintaxis, busca referencias colgantes y secretos escritos en el código y lanza una batería de peticiones contra el resultado. Si pasa en una marca y falla en otra, la entrega espera. La regla de «una sola copia» se vigila con una comparación previa, que antes de portar algo de un árbol a otro obliga a aplicar solo la diferencia.
Qué se gana y qué cuesta
- ✕Radio de un fallo. Un error en el código compartido alcanza a todas las marcas al desplegar.
- ✕Pruebas. Cada cambio se verifica en todas las marcas y no solo en la que lo motivó.
- ✕Condiciones. La opción de marca añade una bifurcación a cada comportamiento que varía.
- ✕Duplicación a mano. Lo que no se comparte en infraestructura se copia y se mantiene en cada stack.
- ✓Sin divergencia. El código común existe una vez y se compara antes de portar nada.
- ✓Entrega única. Un cambio común es un cambio y no uno por repositorio.
- ✓Aislamiento verificable. El ensamblado y las comprobaciones convierten las reglas en resultados.
El paso de ensamblado se convierte en una pieza crítica del flujo de entrega, y la opción de marca se vuelve un coladero de condiciones si se abusa de ella. A cambio desaparece la divergencia, que es el coste que más tarda en aparecer y más cuesta deshacer en las otras dos arquitecturas. El caso real del que parte este patrón, con sus fechas y las alternativas descartadas, está en WordPress en monorepo en vez de multisite.