Panel klienta Aphrodi

Das VulCode-Kundenpanel haben wir für uns selbst gebaut, und heraus kam ein Kern, von dem wir behaupteten, er sei multibrand. Aphrodi war die Gelegenheit, das wirklich zu prüfen. Aphrodi ist eine eigene Marke mit einer eigenen, starken Identität, also durfte ihr Panel nicht wie ein umgefärbtes VulCode aussehen. Es musste sich wie ein Teil von Aphrodi anfühlen und zugleich auf demselben Code stehen wie das Panel der Schwestermarke.

Das ist schwieriger, als es klingt. "Multibrand" zu sagen ist leicht; zu beweisen, dass darunter nicht einfach ein kopiertes Verzeichnis mit von Hand ausgetauschten Farben liegt, ist schwerer. Diese Fallstudie handelt davon, wie wir unsere eigene Architektur unter Druck gesetzt haben und was es bedeutet, dass sie bestanden hat.

Der häufigste Schwindel bei Projekten dieser Art ist, dass Multibrand nur auf der Folie existiert. Im Code sitzen zwei fast identische Verzeichnisse, in denen jemand von Hand die Palette und das Logo ausgetauscht hat. Es sieht aus wie ein gemeinsamer Kern, bis die erste Korrektur kommt. Dann stellt sich heraus, dass man sie zweimal einfügen muss, und bei der dritten Version fängt das Layout an zu driften.

Wir wollten das Gegenteil: dass das Aphrodi-Panel und das VulCode-Panel physisch derselbe Code sind und nicht zwei nebeneinander lebende Kopien. Der Unterschied zwischen ihnen soll eine Deklaration sein und kein Duplikat. Wenn wir verbessern, wie Provisionen berechnet werden oder wie die Rechnungsansicht aussieht, sollen beide Marken diese Verbesserung im selben Commit bekommen, ohne dass etwas neu geschrieben wird.

Das war der echte Test unserer Architektur. Wenn das Hinzufügen einer zweiten Marke eine Verzweigung des Codes erfordert hätte, hieße das, der Kern ist gar nicht multibrand, wir haben ihn nur so genannt.

Die Lösung ist einfach zu beschreiben und anspruchsvoll in der Umsetzung: der Kern ist einer, und eine Marke kommt als Satz von Tokens hinein. Farben, Schriften, Radien, Stimmung - alles, was Aphrodi von VulCode unterscheidet - sind Daten, die der Kern liest und auf die er reagiert. Die Logik, die Bildschirme und der ganze Ablauf sind gemeinsam. Es ändert sich nur die visuelle Schicht, und zwar nicht durch das Austauschen von Dateien, sondern durch die Wahl eines Token-Satzes.

Dadurch sind die Marken nicht zwei Repositories oder zwei Verzeichnisse. Sie sind zwei Einträge in einer Map. Das Panel weiß, für welche Marke es rendert, und greift nach den passenden Tokens, während der Rest des Codes nicht einmal wissen muss, dass es mehr als eine Marke gibt.

Der Wert dieses Ansatzes zeigt sich am besten in der täglichen Arbeit. Wenn wir die Projektansicht verbessern oder die Art, wie das Panel Abrechnungen zeigt, gibt es keine Frage "haben wir dasselbe auch in der anderen Marke gemacht". Die Korrektur kommt einmal hinein und fängt beide, weil es physisch derselbe Code ist. Eine ganze Fehlerklasse verschwindet, in der eine Marke der anderen vorauseilt, weil jemand vergessen hat, die Kopien zu synchronisieren.

Die Trennung ist sauber und leicht zu beschreiben. Gemeinsam sind die Funktionen, die Bildschirme sowie Logik und API. Getrennt sind nur die Palette, die Typografie, die Stimmung und die kleinen Details, die die Identität einer Marke ausmachen. Diese Grenze verläuft genau dort, wo sie soll: der Kern weiß nichts über Farben, und die Markenschicht weiß nichts darüber, wie Provisionen berechnet werden.

Ein Aphrodi-Kunde bekommt ein Werkzeug, das wie Aphrodi aussieht und sich so anfühlt, und nicht wie VulCode in anderen Farben. Es hat den vollen Funktionsumfang eines Kundenpanels, genauso ausgefeilt wie in der Schwestermarke, weil darunter genau derselbe bewährte Kern steckt. Nichts wurde vereinfacht, nur weil es die zweite Marke ist.

Auf unserer Seite ist der Gewinn strukturell. Wir pflegen nicht zwei getrennte Panels, sondern nur einen Kern mit einer Markenschicht obendrauf. Die Architektur hat den Test bestanden, um den es im Projekt ging: Multibrand hat sich als echt erwiesen und nicht als bloß behauptet. Die nächste Marke ist kein weiteres Projekt von Grund auf, sondern nur ein Eintrag in der Token-Map und eine Handvoll Assets, bereit, auf demselben, bereits ausgefeilten Fundament zu sitzen.