Organisationen bekommen ein Gesicht: Kontaktdaten und Profilseiten

Foto: Breather · StockSnap (CC0 1.0), via Openverse

Eine Organisation in Xircuit war bislang erstaunlich anonym. Sie hatte einen Namen, einen Besitzer, ein paar Mitglieder — aber niemand konnte sagen, wo sie eigentlich sitzt, unter welcher Telefonnummer man sie erreicht oder an welche Adresse eine Rechnung geht. Für die ersten Wochen war das kein Problem, weil ich die Datenmodelle bewusst schlank gehalten habe. Doch je näher wir an Abrechnung, öffentliche Auftritte und rechtlich sauberе E-Mails rücken, desto deutlicher wurde: Ohne verlässliche Stammdaten steht das alles auf Sand.

Diese Woche habe ich Organisationen deshalb ein Gesicht gegeben. Es klingt unspektakulär — ein paar Felder für Kontakt und Adresse, eine Seite zum Bearbeiten. Aber hinter dieser Fassade steckt eine Entscheidung, die den ganzen weiteren Weg beeinflusst: Wie modelliert man Daten, die gleichzeitig für sieben sehr unterschiedliche Branchen funktionieren müssen, ohne sie siebenmal zu bauen?

Warum Stammdaten überhaupt zuerst kommen

Es gibt eine Reihenfolge, die sich in solchen Systemen immer wieder durchsetzt: Bevor man etwas mit Daten tun kann, müssen die Daten existieren und verlässlich sein. Abrechnung braucht eine Rechnungsadresse und einen rechtlichen Ansprechpartner. Support braucht eine Telefonnummer und eine E-Mail, an die man sich wenden kann. Und die Marketing-Seiten, die wir später ausspielen wollen, brauchen genau die Angaben, die eine Organisation nach außen zeigen möchte.

Alle diese Funktionen greifen am Ende auf dieselbe Quelle zu. Wenn diese Quelle inkonsistent ist — die Adresse hier anders geschrieben als dort, die Kontakt-E-Mail an drei Stellen dreifach gepflegt — dann vervielfacht sich der Fehler mit jeder Funktion, die darauf aufbaut. Deshalb habe ich mich bewusst dagegen entschieden, Kontaktangaben irgendwo verstreut als lose Textfelder abzulegen. Stattdessen bekommen Organisationen strukturierte Kontakt- und Adressfelder als saubere Stammdaten: getrennte Felder für Straße, Postleitzahl, Ort, Land, für Telefon und E-Mail, für die Website. Struktur statt Freitext, weil Struktur später abfragbar, validierbar und wiederverwendbar ist.

Ein Datenmodell, sieben Branchen

Xircuit bedient sieben Branchen, und jede spricht ihre eigene Sprache. Was in der einen ein "Studio" ist, ist in der anderen eine "Praxis", ein "Verein" oder ein "Standort". Die naheliegende, aber falsche Reaktion wäre, für jede Branche ein eigenes Datenmodell zu bauen. Das hätte uns siebenfache Pflege, siebenfache Migrationen und siebenfache Fehlerquellen beschert.

Der Weg, für den ich mich entschieden habe, trennt sauber zwischen dem, was technisch gleich ist, und dem, was sich nur an der Oberfläche unterscheidet. Die Organization-Entität bekommt die neuen Kontakt- und Adressfelder ein einziges Mal. Darunter liegt genau ein Schema, eine Tabelle, eine Wahrheit. Die Branchen unterscheiden sich nur im Vokabular — in den Beschriftungen, in der Ansprache, in den Hilfetexten. Technisch bleibt es überall dieselbe Struktur. Diese Trennung ist der eigentliche Kern der Woche: Sie erlaubt es, eine Funktion einmal zu bauen und trotzdem sieben verschiedenen Zielgruppen das Gefühl zu geben, sie sei für sie gemacht.

Der Profil-Editor unter /admin/org/

Die neuen Felder brauchen einen Ort, an dem man sie pflegt. Diesen Ort habe ich als eigene Profil-Editor-Seite umgesetzt, erreichbar unter /admin/org/{id}/profile. Sie bündelt die Kontakt- und Adressdaten einer Organisation an einer einzigen Stelle, statt sie über verschiedene Einstellungsdialoge zu verteilen. Wer die Organisation verwaltet, findet hier alles, was das öffentliche und rechtliche Gesicht der Organisation ausmacht.

Die Seite ist eine Blazor-Komponente, die über die Organisations-Id die passende Entität lädt, die Felder in ein Formular bindet und Änderungen serverseitig validiert, bevor sie gespeichert werden. Wichtig war mir, dass sie über alle sieben Branchen hinweg einheitlich funktioniert. Es gibt nicht sieben Editoren, sondern einen — der sich sein Vokabular aus dem Branchenkontext holt. Eine Fitnesskette sieht andere Begriffe als eine Physiotherapiepraxis, arbeitet aber mit demselben Formular, denselben Validierungsregeln und demselben Speicherpfad.

Foto: Rawpixel (CC0 1.0), via Openverse

Vokabular an der Oberfläche, Technik darunter

Wie löst man das konkret, dass dieselbe Seite je nach Branche anders spricht? Der Trick liegt darin, die Beschriftungen nicht fest in die Komponente zu schreiben, sondern sie über den Branchenkontext aufzulösen. Die Oberfläche folgt dem branchenabhängigen Vokabular, bleibt aber technisch dieselbe. Ein Feld heißt intern schlicht AddressLine — was der Nutzer als Label liest, entscheidet die Branche der jeweiligen Organisation.

Das hat einen angenehmen Nebeneffekt für die Wartung. Wenn ich das Kontaktmodell später erweitere, etwa um ein Feld für eine zweite Rufnummer oder eine Umsatzsteuer-Identifikationsnummer, dann passiert das an genau einer Stelle. Die sieben Branchen erben die Änderung automatisch; ich muss lediglich das jeweilige Vokabular ergänzen. Das ist die Sorte Entscheidung, die sich in den ersten Wochen kaum bemerkbar macht und einen ein halbes Jahr später dankbar auf sein früheres Ich zurückblicken lässt.

Was auf diesen Daten aufbaut

Der eigentliche Wert dieser Woche zeigt sich erst später, wenn andere Bausteine andocken. Die Kontaktdaten speisen künftig gleich mehrere Funktionen: öffentliche Auftritte einer Organisation, ausgehende E-Mails und rechtliche Angaben. Wenn wir eine Bestätigungs-Mail verschicken, kann in der Fußzeile die echte Adresse und der reale Ansprechpartner der Organisation stehen, statt eines generischen Platzhalters. Wenn eine Organisation eine öffentliche Seite bekommt, zieht diese ihre Angaben aus denselben Feldern. Und wenn es um rechtlich verpflichtende Angaben geht, gibt es endlich eine kanonische Quelle dafür.

Genau deshalb war es mir wichtig, das Fundament sauber zu legen, bevor darauf gebaut wird. Konsistente Stammdaten sind die stille Voraussetzung für Abrechnung, Support und Marketing-Seiten gleichermaßen. Keine dieser drei Funktionen ist besonders spektakulär in dem Moment, in dem man die Kontaktfelder anlegt — aber jede von ihnen wäre unnötig fehleranfällig geworden, hätte man die Daten weiterhin verstreut und unstrukturiert gehalten. Ich betrachte diese Woche daher weniger als ein Feature für sich und mehr als eine Investition, die sich in den kommenden Wochen mehrfach auszahlt.

Ein bewusst unauffälliger Baustein

Nicht jede Woche in einem Produkt bringt ein sichtbares neues Fenster oder eine Funktion, über die man sofort spricht. Diese hier gehört zu den unauffälligen — und gerade deshalb mag ich sie. Ein Datenmodell, das für sieben Branchen zugleich trägt, ein Editor, der überall gleich funktioniert und trotzdem überall passend klingt, und Stammdaten, die endlich verlässlich genug sind, um darauf zu bauen. Das ist die Art Arbeit, die man später nicht mehr sieht, weil alles darauf einfach funktioniert.

Was kommt als Nächstes?

Nächste Woche: Observability für sieben Worker — Sentry in jedem Hintergrunddienst, mit eigenem DSN.