Panel klienta Aphrodi

El panel de cliente de VulCode lo construimos para nosotros mismos, y de ahí salió un núcleo del que afirmábamos que era multimarca. Aphrodi fue la ocasión de comprobarlo de verdad. Aphrodi es una marca aparte con su propia identidad fuerte, así que su panel no podía parecer un VulCode repintado. Tenía que sentirse como parte de Aphrodi y a la vez apoyarse en el mismo código que el panel de la marca hermana.

Es más difícil de lo que suena. Decir "multimarca" es fácil; demostrar que debajo no hay simplemente un directorio copiado con los colores cambiados a mano es más difícil. Este caso de estudio trata de cómo pusimos a prueba nuestra propia arquitectura a fondo y qué significa que la haya superado.

El engaño más común en proyectos de este tipo es que lo multimarca solo existe en la diapositiva. En el código hay dos directorios casi idénticos en los que alguien cambió a mano la paleta y el logo. Parece un núcleo común hasta que llega la primera corrección. Entonces resulta que hay que pegarla dos veces, y en la tercera versión el diseño empieza a divergir.

Nosotros queríamos lo contrario: que el panel de Aphrodi y el panel de VulCode fueran físicamente el mismo código, y no dos copias que viven una al lado de la otra. La diferencia entre ellos debe ser una declaración, no un duplicado. Si mejoramos cómo se calculan las comisiones o cómo se ve la vista de facturas, ambas marcas deben recibir esa mejora en el mismo commit, sin reescribir nada.

Esa era la prueba real de nuestra arquitectura. Si añadir una segunda marca hubiera exigido ramificar el código, habría significado que el núcleo no era multimarca en absoluto, solo lo llamábamos así.

La solución es sencilla de describir y exigente de ejecutar: el núcleo es uno solo, y una marca entra como un conjunto de tokens. Colores, fuentes, radios, ambiente - todo lo que distingue a Aphrodi de VulCode - son datos que el núcleo lee y a los que reacciona. La lógica, las pantallas y todo el flujo son comunes. Solo cambia la capa visual, y no cambiando archivos sino eligiendo un conjunto de tokens.

Gracias a eso, las marcas no son dos repositorios ni dos directorios. Son dos entradas en un único mapa. El panel sabe para qué marca renderiza y va a por los tokens correctos, mientras el resto del código ni siquiera tiene que saber que hay más de una marca.

El valor de este enfoque se ve mejor en el trabajo diario. Cuando mejoramos la vista de proyectos o la forma en que el panel muestra la facturación, no hay pregunta de "hicimos lo mismo en la otra marca". La corrección entra una vez y atrapa a ambas, porque es físicamente el mismo código. Desaparece toda una clase de errores en la que una marca se adelanta a la otra porque alguien se olvidó de sincronizar las copias.

La separación es limpia y fácil de describir. Comunes son las funciones, las pantallas, la lógica y la API. Separados son solo la paleta, la tipografía, el ambiente y los pequeños detalles que construyen la identidad de una marca. Esa línea pasa exactamente donde debe: el núcleo no sabe nada de los colores, y la capa de marca no sabe nada de cómo se calculan las comisiones.

Un cliente de Aphrodi obtiene una herramienta que se ve y se siente como Aphrodi, y no como VulCode en otros colores. Tiene el conjunto completo de funciones de un panel de cliente, tan pulido como en la marca hermana, porque debajo es exactamente el mismo núcleo probado. Nada se simplificó solo porque es la segunda marca.

En nuestro lado la ganancia es estructural. No mantenemos dos paneles separados, solo un núcleo con una capa de marca encima. La arquitectura superó la prueba de la que trataba el proyecto: lo multimarca resultó ser real, no declarado. La siguiente marca no es otro proyecto desde cero, solo una entrada en el mapa de tokens y un puñado de assets, lista para asentarse sobre el mismo cimiento ya pulido.