E-Mobilitäts-Marktplatz für Beyond Move
Ein E-Mountainbike, ein E-Scooter und ein Bremssattel gehören auf denselben Marktplatz und haben fast nichts gemeinsam, was man über sie wissen will. Für Beyond Move hat Batunet das Inserat deshalb nicht über feste Spalten gebaut, sondern über ein Merkmalsmodell, das Kategorien zugeordnet wird — und das Eingabeformular und Filter aus derselben Definition speist.
Der Fall in einer Minute.
- Rolle
- Neuentwicklung von Laravel-API, Nuxt-Frontend und Verwaltungsoberfläche — Datenmodell, Kategorie- und Merkmalslogik, Inseratsprozess, Suche und Nachrichten.
- Zeitraum
- Entwicklung von März bis Juli 2021; Ausbau von Juli bis Oktober 2022 mit neuer Nachrichtenfunktion und Performance-Optimierung.
- Systemklasse
- Öffentlicher Marktplatz für E-Mobilität. Anbieter sind gewerbliche Händler und Privatverkäufer; die Oberfläche ist deutschsprachig.
- Produktbereiche
- E-Bikes mit mehrstufiger Unterteilung, E-Scooter, E-Skates sowie E-Bike-Teile — 35 Kategorien in einem gemeinsamen Baum, dazu ein Marken- und Modellverzeichnis.
- Produktdatenmodell
- Merkmale liegen nicht als feste Spalten am Inserat, sondern als eigene Felddefinitionen mit getrennt gespeicherten Werten. Sie werden Kategorien zugeordnet; die Zuordnung führt den Kategoriepfad mit.
- Ausgelieferte Merkmalskonfiguration
- 17 Merkmalsfelder, zugeordnet an die Kategorien des E-Bike-Zweigs und an E-Scooter. E-Skates und E-Bike-Teile führen keines dieser Felder.
- Suche und Filter
- Kategoriefilter über den Kategoriepfad, Marken- und Modellfilter, Merkmalsfilter mit Auswahl-, Text- und Bereichsvergleich. Ortsangabe mit Koordinaten je Inserat.
- Marktplatzfunktionen
- Inserate mit Statusverwaltung durch die Verwaltung; Anlage, Änderung, Löschung und Statuswechsel werden protokolliert. Dazu Nachrichten zwischen Nutzern, Verkäuferbewertung, Merkliste und inseratsbezogene Kontaktfreigabe.
- Technisches Umfeld
- Laravel 8 als REST-API mit tokenbasierter Anmeldung, Nuxt 2 mit serverseitigem Rendering, eine Vue-Anwendung für die Verwaltung, MySQL.
- Abgrenzung
- Frontend und Verwaltung bauen auf lizenzierten UI-Vorlagen auf, die für den Marktplatz angepasst wurden.
Ein Marktplatz, auf dem nichts vergleichbar ist.
Ein Marktplatz lebt davon, dass Angebote vergleichbar werden. Genau das ist bei Beyond Move die Schwierigkeit. Ein E-Mountainbike beschreibt man über Rahmenform, Federweg, Motor und Akku. Einen E-Scooter über ganz andere Größen. Ein Bremssattel hat mit beidem nichts zu tun, gehört aber auf denselben Marktplatz — denn wer ein E-Bike kauft, kauft irgendwann Teile dafür.
Der naheliegende Weg wäre, die Merkmale als Spalten an das Inserat zu schreiben. Er funktioniert für eine Produktart und bricht bei der zweiten: Entweder man führt eine Tabelle mit Spalten, die für die meisten Inserate leer bleiben, oder man baut pro Produktart ein eigenes Inserat — und damit einen zweiten Marktplatz neben dem ersten.
Beide Wege verschieben dieselbe Frage nur nach hinten. Die eigentliche Aufgabe war deshalb nicht, die richtigen Merkmale zu finden, sondern das Inserat so zu bauen, dass es nicht wissen muss, welche Merkmale es einmal tragen wird.
Merkmale als Daten, nicht als Spalten.
Ein Merkmal ist in diesem System kein Feld im Code, sondern ein Datensatz. Eine Felddefinition trägt ihren Typ, ihre Auswahlmöglichkeiten, eine Regelangabe, ihre Reihenfolge, ob sie Pflicht ist und ob sie in Suche und Filter erscheinen soll. Die eingetragenen Werte liegen getrennt davon und verweisen auf die Definition und das Inserat.
Dadurch zerfällt das Inserat in zwei Schichten. Die eine ist für jedes Angebot gleich und liegt fest am Datensatz: Titel, Beschreibung, Bilder, Preis, Zustand, Ort. Die andere hängt davon ab, in welcher Kategorie das Angebot steht — und ist keine Programmierentscheidung, sondern eine Zuordnung im Datenbestand.
Der Preis dafür ist ehrlich zu benennen: Ein solches Modell tauscht Datenbankstruktur gegen Beweglichkeit. Man verliert die Selbstauskunft der Tabelle — ein Blick in das Schema sagt nicht mehr, welche Merkmale ein E-Bike hat. Man gewinnt dafür, dass eine neue Merkmalsanforderung kein Schemawechsel ist. Für einen Marktplatz, dessen Sortiment sich schneller ändert als seine Software, ist das der richtige Tausch.
- Gemeinsame Angebotsdaten
- Titel, Beschreibung und Bildergalerie, Preis und Preisangabe, Zustand, Versandbereitschaft, Montagehinweis, Ort mit Koordinaten
- Kategorie und Taxonomie
- Kategoriebaum mit Pfadangabe je Knoten, Marke und Modell, Pfadkopie in den Zuordnungen, Kategoriebezogene Seitenangaben
- Dynamische Merkmale
- Felddefinition mit Typ, Optionen und Regelangabe, Werte getrennt vom Inserat gespeichert, Zuordnung zu Kategorien, Reihenfolge, Pflichtangabe, Such- und Filterkennzeichen
- Auffinden
- Kategoriefilter über den Pfad, Marken- und Modellfilter, Merkmalsfilter mit Auswahl, Text und Bereich, Formular und Filter aus denselben Definitionen
Der Weg eines Inserats.
Der Weg eines Inserats ist der Punkt, an dem sich das Datenmodell zeigt. Er beginnt nicht mit einem Formular, sondern mit einer Entscheidung: Erst wenn die Kategorie feststeht, steht fest, wonach überhaupt gefragt wird.
Wichtig ist dabei, was das Frontend nicht tut. Es kennt keine Feldliste. Es lädt für die gewählte Kategorie die zugeordneten Felddefinitionen aus der API und wählt die Darstellung je Feldtyp. Dieselben Definitionen erzeugen später die Filter. Eingabe und Suche können deshalb nicht auseinanderlaufen — sie stammen aus derselben Quelle.

- 01
Kategorie wählen
Die Kategorie entscheidet, welche Merkmale das Formular überhaupt anbietet.
- 02
Felder laden
Die Felddefinitionen der Kategorie kommen aus der API; die Oberfläche hat keine fest verdrahtete Feldliste und wählt die Darstellung je Feldtyp.
- 03
Angebot erfassen
Gemeinsame Angebotsdaten, Marke und Modell, Bilder sowie die Merkmale der gewählten Kategorie. Fehlt eine Marke oder ein Modell im Verzeichnis, kann es beim Inserieren angelegt werden.
- 04
Werte ablegen
Die Merkmalswerte werden getrennt vom Inserat gespeichert und über die Felddefinition wieder zusammengeführt.
- 05
Veröffentlichen
Das Inserat wird veröffentlicht; die Verwaltung kann seinen Status jederzeit umstellen, und jeder Statuswechsel wird protokolliert.
- 06
Auffindbar werden
Veröffentlichte Inserate erscheinen in Kategorie, Suche und Filter und sind über die Nachrichtenfunktion oder die freigegebenen Kontaktwege erreichbar.
Ein Baum, der mitrechnet.
Der Kategoriebaum ist hier kein Navigationselement, sondern ein Rechenweg. Jede Kategorie trägt neben ihrem Elternverweis eine Pfadangabe, die ihre Stellung im Baum als Zeichenkette abbildet. Diese Pfadangabe wird beim Speichern automatisch fortgeschrieben, auch für die darunterliegenden Knoten.
Das hat eine Folge, die den Ausschlag gegeben hat: Der Kategoriefilter wird zu einem Präfixvergleich statt zu einem rekursiven Durchlauf. Eine Anfrage nach einem Ast findet alles, was darunter liegt, in einem Schritt — Inserate ebenso wie die Merkmale, die den Kategorien dieses Astes zugeordnet sind.
Diese Bequemlichkeit hat eine Kehrseite, die zur Architektur gehört: Der Pfad liegt nicht nur an der Kategorie, sondern auch als Kopie in den Zuordnungstabellen zu Inseraten, Merkmalen und Marken. Solange der Baum wächst, ist das unproblematisch. Wird er umgehängt, müssen diese Kopien mitgeführt werden. Der Baum ist damit erweiterbar, aber nicht beliebig umsortierbar — eine Eigenschaft, die man kennen muss, bevor man sie braucht.
Filtern, was es in dieser Kategorie überhaupt gibt.
Eine Filterleiste, die für jedes Angebot dieselben Felder anbietet, ist auf einem gemischten Marktplatz unbrauchbar. Deshalb entsteht auch die Filterleiste aus den Merkmalsdefinitionen der gewählten Kategorie — sie zeigt, was dort tatsächlich zugeordnet ist, und nichts darüber hinaus.
Auf der Abfrageseite verlangt das Modell mehr Sorgfalt als eine Spaltensuche. Werte liegen nicht in typisierten Spalten, sondern als eigene Datensätze. Die Filterung übersetzt deshalb je Merkmalstyp: Mehrfachauswahl als Mengenvergleich, Freitext als Teilstringsuche, Zahlenbereiche als Ober- und Untergrenze. Marken- und Modellfilter greifen daneben direkt auf das Verzeichnis, der Kategoriefilter auf den Pfad.
Eine Entscheidung ist dabei bewusst restriktiv: Es wird nicht nach jedem Merkmal gefiltert, das in der Anfrage steht, sondern nur nach denen, die der gewählten Kategorie zugeordnet sind. Alles andere wird verworfen. Ohne diese Prüfung würde eine offene Merkmalsstruktur zu einer offenen Abfrageschnittstelle — und Beweglichkeit im Datenmodell darf nicht zu Beweglichkeit in der Datenbankabfrage werden.
Der Marktplatz endet vor dem Kauf.
Ein Marktplatz ist kein Shop mit vielen Verkäufern. Er verkauft nichts. Er führt zusammen — und alles, was er an Mechanik braucht, folgt aus dieser einen Eigenschaft.
Anbieter treten in zwei Rollen auf: als gewerbliche Händler mit eigenem Profil und eigener Anbieterseite, auf der ihre weiteren Angebote zusammenlaufen, und als Privatverkäufer. Ein abgestuftes Rollen- und Rechtemodell trennt davon die redaktionellen und administrativen Zugänge. Die Verwaltung steuert den Status jedes Inserats; Anlage, Änderung, Löschung und Statuswechsel werden protokolliert, damit im Nachhinein nachvollziehbar bleibt, wer was verändert hat.
Der Kontakt zwischen Käufer und Anbieter ist Teil des Produkts: eine Nachrichtenfunktion mit Verlauf, Dateianhang, Gelesen-Kennzeichen und Benachrichtigung per E-Mail, dazu eine Merkliste und eine Bewertung des Anbieters. Ob E-Mail-Adresse und Telefonnummer sichtbar sind, entscheidet der Anbieter je Inserat. Was es bewusst nicht gibt, ist ein Warenkorb, eine Kaufabwicklung oder eine Zahlungsstrecke. Der Abschluss findet zwischen den Beteiligten statt. Das ist keine Lücke, sondern die Definition des Systems — und es hält eine ganze Klasse von Anforderungen aus einem Produkt heraus, das sie nicht braucht.
Was ein Modell kann und was von ihm genutzt wird.
Ein Datenmodell und seine Konfiguration sind zwei verschiedene Dinge, und es lohnt sich, sie auseinanderzuhalten.
Das Modell trägt kategorieabhängige Merkmale, pfadbasierte Abfragen über den Kategoriebaum, typabhängige Darstellung und typabhängige Filterung. Die ausgelieferte Erstkonfiguration hat davon einen Ausschnitt genutzt: 17 Merkmalsfelder, einzeln zugeordnet an die Kategorien des E-Bike-Zweigs und an E-Scooter, inhaltlich am Fahrrad orientiert. E-Skates und E-Bike-Teile führen keines dieser Felder — sie werden über die gemeinsamen Angebotsdaten und den Kategoriebaum getragen.
Man kann das als unfertig lesen. Wir lesen es anders: Ein Marktplatz startet mit dem Sortiment, das ihn trägt, und wächst in die übrigen Bereiche hinein. Der Unterschied liegt darin, was dieses Hineinwachsen kostet. In einem Modell mit festen Spalten wäre jede neue Produktwelt eine Schemaänderung mit Migration und Auslieferung gewesen. Hier ist sie eine Zuordnung im Datenbestand. Dass die Fähigkeit zum Startzeitpunkt nicht ausgereizt wurde, ist kein Argument gegen sie — es ist der Grund, warum sie gebaut wurde.
Zwei Ausbaustufen.
Die Versionshistorie zeigt zwei Phasen: die Neuentwicklung im Frühjahr und Sommer 2021 und einen zweiten Ausbau im Sommer und Herbst 2022. Dazwischen und danach lagen kleinere Anpassungen.
- 01
März bis Juli 2021
Laravel-API, Nuxt-Frontend und Verwaltung, Kategorie- und Merkmalsmodell, Inseratsprozess, Suche und Filter.
- 02
Ende 2021 bis Mitte 2022
Suchmaschinen-Grundlagen: Sitemap aus der API, Robots-Angaben, Canonical-Anpassungen.
- 03
Juli 2022
Performance-Optimierung des Frontends mit Code-Splitting und verzögertem Laden.
- 04
August bis Oktober 2022
Neue Nachrichtenfunktion mit Unterhaltungen, Dateianhang und E-Mail-Benachrichtigung über eine Queue.
Woran dieser Fall anschließt.
Fragen zu diesem Fall
Wie bildet man völlig unterschiedliche Produktarten in einem Marktplatz ab?
Indem man die Merkmale aus dem Inserat herauszieht. Bei Beyond Move liegen sie nicht als feste Spalten am Angebot, sondern als eigene Definitionen mit getrennt gespeicherten Werten, die Kategorien zugeordnet werden. Eine neue Merkmalsanforderung ist damit eine Datenfrage und keine Schemaänderung.
Worin unterscheidet sich ein Marktplatz von einem Onlineshop?
Ein Shop verkauft, ein Marktplatz führt zusammen. Das ändert nahezu jede Anforderung: viele Anbieter statt eines Sortiments, eine Statusverwaltung von Inseraten statt einer Pflege von Artikeln, Kontaktwege zwischen Nutzern statt einer Kaufstrecke. In diesem System gibt es bewusst keinen Warenkorb und keine Zahlungsabwicklung — der Abschluss findet zwischen den Beteiligten statt.
Können neue Kategorien und Merkmale ohne Entwicklung eingerichtet werden?
In den vorgesehenen Grenzen ja. Kategorien und Merkmalsdefinitionen sind Daten, und ihre Zuordnung zueinander ist in der Verwaltung pflegbar; Eingabeformular und Filter folgen der Zuordnung, ohne dass dafür Code geändert wird. Umfassendere Eingriffe — etwa das Umhängen bestehender Äste oder neue Merkmalstypen mit eigener Darstellung — sind Entwicklungsarbeit. Wir beschreiben Administrierbarkeit deshalb als das, was sie ist: weit, aber nicht unbegrenzt.
Warum liegen die Merkmale nicht einfach als Spalten am Inserat?
Weil das nur für eine Produktart funktioniert. Bei mehreren führt es zu einer Tabelle, deren Spalten für die Mehrheit der Datensätze leer bleiben, oder zu getrennten Inseratsarten und damit zu mehreren Marktplätzen in einem System. Der Tausch, den wir stattdessen eingegangen sind, kostet Selbstauskunft im Datenbankschema und Sorgfalt bei den Abfragen — und er ist der Grund, warum das Sortiment wachsen kann, ohne dass die Software es vorher wissen muss.
Warum nennen Sie keine Nutzungszahlen?
Weil die Engineering-Leistung ohne sie vollständig beschreibbar ist. Produktdatenmodell, Kategorielogik, Inseratsprozess, Suche und Marktplatzmechanik stehen für sich, und Nutzungszahlen sagen über die Qualität eines Datenmodells ohnehin wenig aus.
Setzen Sie Ihren Engineering-Weg fort.
Verwandte Konzepte, Entscheidungen, Playbooks und Standpunkte — als zusammenhängender Pfad, nicht als Linkliste.
Sprechen wir über Ihr Vorhaben.
Kein Vertrieb. Ein direktes Gespräch mit der Geschäftsführung.
