Panel klienta Aphrodi

Il pannello cliente VulCode l'abbiamo costruito per noi stessi, e ne è uscito un nucleo che sostenevamo fosse multibrand. Aphrodi è stata l'occasione per verificarlo davvero. Aphrodi è un marchio distinto con una propria, forte identità, quindi il suo pannello non poteva sembrare un VulCode riverniciato. Doveva sentirsi come parte di Aphrodi e allo stesso tempo poggiare sullo stesso codice del pannello del marchio gemello.

È più difficile di quanto sembri. Dire "multibrand" è facile; dimostrare che sotto non c'è semplicemente una cartella copiata con i colori sostituiti a mano è più difficile. Questo caso di studio racconta come abbiamo messo alla prova la nostra stessa architettura e cosa significa che l'abbia superata.

L'inganno più comune nei progetti di questo tipo è che il multibrand esista solo sulla slide. Nel codice stanno due cartelle quasi identiche in cui qualcuno ha sostituito a mano la palette e il logo. Sembra un nucleo comune finché non arriva la prima correzione. Allora si scopre che va incollata due volte, e alla terza versione il layout inizia a divergere.

Noi volevamo il contrario: che il pannello Aphrodi e il pannello VulCode fossero fisicamente lo stesso codice, e non due copie che vivono l'una accanto all'altra. La differenza tra loro deve essere una dichiarazione, non un duplicato. Se miglioriamo il modo in cui si calcolano le commissioni o l'aspetto della vista delle fatture, entrambi i marchi devono ricevere quel miglioramento nello stesso commit, senza riscrivere nulla.

Era il vero test della nostra architettura. Se aggiungere un secondo marchio avesse richiesto di ramificare il codice, avrebbe significato che il nucleo non era affatto multibrand, lo avevamo solo chiamato così.

La soluzione è semplice da descrivere ed esigente da realizzare: il nucleo è uno solo, e un marchio entra come un insieme di token. Colori, font, raggi, atmosfera - tutto ciò che distingue Aphrodi da VulCode - sono dati che il nucleo legge e a cui reagisce. La logica, le schermate e l'intero flusso sono comuni. Cambia solo il livello visivo, e non sostituendo file ma scegliendo un insieme di token.

Grazie a questo i marchi non sono due repository né due cartelle. Sono due voci in un'unica mappa. Il pannello sa per quale marchio sta rendendo e prende i token giusti, mentre il resto del codice non deve nemmeno sapere che i marchi sono più di uno.

Il valore di questo approccio si vede meglio nel lavoro quotidiano. Quando miglioriamo la vista dei progetti o il modo in cui il pannello mostra i pagamenti, non c'è la domanda "abbiamo fatto lo stesso nell'altro marchio". La correzione entra una volta e prende entrambi, perché è fisicamente lo stesso codice. Sparisce un'intera classe di bug in cui un marchio va avanti rispetto all'altro perché qualcuno si è dimenticato di sincronizzare le copie.

La separazione è netta e facile da descrivere. Comuni sono le funzioni, le schermate, la logica e l'API. Separati sono solo la palette, la tipografia, l'atmosfera e i piccoli dettagli che costruiscono l'identità di un marchio. Questa linea passa esattamente dove deve: il nucleo non sa nulla dei colori, e il livello del marchio non sa nulla di come si calcolano le commissioni.

Un cliente Aphrodi ottiene uno strumento che sembra ed è al tatto Aphrodi, e non VulCode in altri colori. Ha l'insieme completo di funzioni di un pannello cliente, curato quanto nel marchio gemello, perché sotto c'è esattamente lo stesso nucleo collaudato. Nulla è stato semplificato solo perché è il secondo marchio.

Dalla nostra parte il guadagno è strutturale. Non manteniamo due pannelli separati, ma un solo nucleo con un livello di marchio sopra. L'architettura ha superato il test di cui il progetto trattava: il multibrand si è rivelato reale, non dichiarato. Il prossimo marchio non è un altro progetto da zero, ma solo una voce nella mappa dei token e una manciata di asset, pronta a poggiare sulla stessa fondazione già curata.