Panel klienta Aphrodi

Panel klienta VulCode budowaliśmy dla siebie i wyszedł z niego rdzeń, o którym twierdziliśmy, że jest wielomarkowy. Aphrodi był okazją, żeby to sprawdzić naprawdę. Aphrodi to osobna marka z własną, mocną identyfikacją, więc jej panel nie mógł wyglądać jak przemalowany VulCode. Musiał czuć się jak część Aphrodi, a jednocześnie stać na tym samym kodzie, co panel siostrzanej marki.

To jest trudniejsze, niż brzmi. Łatwo powiedzieć "wielomarkowe", trudniej udowodnić, że pod spodem nie ma po prostu skopiowanego katalogu z ręcznie podmienionymi kolorami. Ten case study jest o tym, jak sprawdziliśmy własną architekturę na ostro i co to znaczy, że zdała.

Najczęstsza ściema w tego typu projektach polega na tym, że wielomarkowość jest tylko na slajdzie. W kodzie siedzą dwa niemal identyczne katalogi, w których ktoś ręcznie podmienił paletę i logo. Wygląda to jak wspólny rdzeń, dopóki nie wejdzie pierwsza poprawka. Wtedy okazuje się, że trzeba ją wkleić dwa razy, a przy trzeciej wersji układ zaczyna się rozjeżdżać.

My chcieliśmy przeciwieństwa: żeby panel Aphrodi i panel VulCode były fizycznie tym samym kodem, a nie dwiema kopiami żyjącymi obok siebie. Różnica między nimi ma być deklaracją, a nie duplikatem. Jeśli poprawiamy sposób, w jaki liczą się prowizje albo jak wygląda widok faktur, obie marki mają dostać tę poprawkę tym samym commitem, bez przepisywania niczego.

To był realny test naszej architektury. Jeśli dołożenie drugiej marki wymagałoby rozgałęzienia kodu, znaczyłoby, że rdzeń wcale nie jest wielomarkowy, tylko tak go nazywaliśmy.

Rozwiązanie jest proste w opisie i wymagające w wykonaniu: rdzeń jest jeden, a marka wchodzi jako zestaw tokenów. Kolory, fonty, promienie, klimat - wszystko, co odróżnia Aphrodi od VulCode - to dane, które rdzeń czyta i na które reaguje. Logika, ekrany i cały przepływ są wspólne. Zmienia się wyłącznie warstwa wizualna, i to nie przez podmianę plików, tylko przez wybór zestawu tokenów.

Dzięki temu marki nie są dwoma repozytoriami ani dwoma katalogami. Są dwoma wpisami w jednej mapie. Panel wie, dla której marki się renderuje, i sięga po odpowiednie tokeny, a reszta kodu nawet nie musi wiedzieć, że marek jest więcej niż jedna.

Najlepiej widać wartość tego podejścia w codziennej pracy. Kiedy poprawiamy widok projektów albo sposób, w jaki panel pokazuje rozliczenia, nie ma pytania "a czy zrobiliśmy to samo w drugiej marce". Poprawka wchodzi raz i łapie obie, bo to fizycznie ten sam kod. Znika cała klasa błędów, w których jedna marka wyprzedza drugą, bo ktoś zapomniał zsynchronizować kopie.

Rozdział jest czysty i łatwo go opisać. Wspólne są funkcje, ekrany oraz logika i API. Osobne są tylko paleta, typografia, klimat i drobne detale, które budują tożsamość marki. Ta granica biegnie dokładnie tam, gdzie powinna: rdzeń nie wie nic o kolorach, a warstwa marki nie wie nic o tym, jak liczą się prowizje.

Klient Aphrodi dostaje narzędzie, które wygląda i czuje się jak Aphrodi, a nie jak VulCode w innych barwach. Ma pełny zestaw funkcji panelu klienta, tak samo dopracowany jak w marce siostrzanej, bo pod spodem to dokładnie ten sam, sprawdzony rdzeń. Nic nie zostało uproszczone tylko dlatego, że to druga marka.

Po naszej stronie zysk jest strukturalny. Nie utrzymujemy dwóch osobnych paneli, tylko jeden rdzeń z warstwą marki na wierzchu. Architektura zdała test, o który w tym projekcie chodziło: wielomarkowość okazała się prawdziwa, a nie deklarowana. Kolejna marka to nie kolejny projekt od zera, tylko wpis w mapie tokenów i garść assetów, gotowa wejść na ten sam, już dopracowany fundament.