Zum Inhalt springen

Das Entity-System

Das Entity-System ist das Fundament, auf dem alle Module von buzzle Commerce Core aufbauen. Es ist ein deklaratives, attributbasiertes Framework: Eine Entität – etwa eine Firma, ein Auftrag oder ein Standort – wird nicht als handgeschriebene Tabelle plus Controller plus Validierung plus Suchanbindung umgesetzt, sondern einmal als Struktur beschrieben. Aus dieser einen Beschreibung leitet die Plattform automatisch alles Weitere ab.

Konsolidiertes Domänenmodell von buzzle Commerce Core: Unternehmen, Personen und Organisationseinheiten sind mit Identity und Rollen verbunden. Katalog, Produkte, Preise und Konditionen führen über Warenkorb und Checkout zu Auftrag und Belegen. Zahlung, Lieferung, Retouren und Services schliessen den Prozess ab. Entity-System, Suche, Validierung, Audit, Messaging und Integration wirken domänenübergreifend.

Das Domänenmodell bildet die wiederkehrenden Bausteine aus B2B-, B2C- und hybriden Commerce-Lösungen in einer gemeinsamen Sprache ab. Im Zentrum stehen vier Zusammenhänge:

  • Organisation und Identity: Unternehmen gruppieren Personen, Einheiten, Adressen und fachliche Rollen. Der Identity-Dienst übernimmt Login, Sessions und technische Berechtigungen; die Plattform hält die fachliche Zuordnung.
  • Katalog und Konditionen: Produkte und Sortimente werden mit Preislisten, Verfügbarkeiten und kundenbezogenen Kaufbedingungen kombiniert.
  • Warenkorb und Bestellung: Ein konfigurierbarer Lebenszyklus führt von Positionen und Preiszeilen über Prüfung und Checkout zum verbindlichen Auftrag.
  • Fulfillment und Services: Zahlungen, Lieferungen, Belege, Retouren und wiederkehrende Services bleiben mit dem ursprünglichen Kunden- und Bestellkontext verbunden.

Die Darstellung ist ein konsolidiertes Produktmodell, kein physisches Datenbankschema. Welche Entitäten und Beziehungen aktiviert werden, hängt von den eingesetzten Modulen und der konkreten Lösung ab. Projektspezifische Fachobjekte können über dieselben Mechanismen ergänzt werden, ohne das gemeinsame Grundmodell aufzugeben.

Wer das PIM kennt, erkennt das Prinzip wieder: Wie das flexible Objektmodell des buzzle PIM bildet auch der Core seine Daten über frei definierbare Strukturen und Attribute ab – hier für den gesamten Commerce-Layer.

Eine Entität wird über einen EntityStructure-Builder beschrieben: mit einer Kennung und einem Namen, einem Anzeigeformat (Label), thematischen Attributgruppen und einer Reihe von Eigenschaften (Attributen). Jede Eigenschaft hat einen Attributtyp, optionale Einstellungen, Übersetzungen, Standardwerte und eine Gruppenzuordnung.

Aus dieser einen Definition erzeugt und pflegt die Plattform:

  • das Datenbank-Schema – Tabellen, Spalten, berechnete Spalten, Indizes, Fremdschlüssel und Unique-Constraints,
  • die CRUD-Endpunkte – Lesen, Anlegen, Ändern und Löschen der Entität über REST,
  • die Suche – Aufnahme ausgewählter Felder in den Suchindex mit Sortierung, Trefferspalten und Filtern,
  • die Validierung – Pflichtfelder, Formate, Eindeutigkeit und eigene Regeln,
  • die Relationen – Verknüpfungen zu anderen Entitäten samt Lösch- und Traversierungsregeln,
  • die Change-Requests – optionale Freigabeprozesse für Wertänderungen,
  • die Notizen, die Berechtigungen auf Datensatzebene und den Audit-Trail.

Das ist der Kern der Aussagekraft des Systems: Ein Entwickler beschreibt das Was, die Plattform liefert das Wie.

  • Konsistenz. Jede Entität folgt denselben Mustern – Endpunkte, Validierung, Suche, Audit funktionieren überall gleich, weil sie aus demselben Mechanismus stammen.
  • Geschwindigkeit. Eine neue Entität ist eine Definition, kein Stapel aus Tabelle, Repository, Controller, Validator, Suchanbindung und Migration.
  • Erweiterbarkeit. Eine zusätzliche Eigenschaft ist eine zusätzliche Zeile in der Definition – Schema, API, Suche und Validierung ziehen automatisch mit.
  • Weniger Fehlerquellen. Was nicht von Hand verdrahtet wird, kann nicht auseinanderlaufen.
  • Mehrsprachigkeit und Konfiguration sind eingebaut. Übersetzungen, Gruppen, Standardwerte und feldspezifische Einstellungen gehören zum Modell, nicht zum Beiwerk.

Eine EntityStructure setzt sich aus wenigen, klaren Bausteinen zusammen:

  • Identität – eine stabile Kennung und ein Name für die Entität.
  • Label-Format – wie ein Datensatz benannt angezeigt wird (etwa {Name}).
  • Attributgruppen – thematische Bündel wie „Allgemeine Angaben”, „Juristische Angaben” oder „Adresse”, jeweils mit Reihenfolge.
  • Eigenschaften (Attribute) – die eigentlichen Felder, jeweils mit Attributtyp, Einstellungen, Übersetzungen, Standardwert, Gruppenzuordnung und optionaler Suchindex-Aufnahme.
  • RelationenVerknüpfungen zu anderen Entitäten.
  • RegelnValidierung und Constraints, die Datenintegrität sicherstellen.

Ändert sich eine Definition, gleicht die Plattform das Datenbank-Schema automatisch an den neuen Sollzustand an – sie legt fehlende Spalten, Indizes, Fremdschlüssel und Constraints an. So bleibt das Schema stets in Deckung mit der Definition, ohne dass Migrationen von Hand geschrieben werden müssen.

Das Entity-System ist keine Randfunktion, sondern der gemeinsame Nenner aller Module. Firmen und Personen im Business-Modul, Warenkörbe und Aufträge im Order-Modul, Produkte im Catalog-Modul, Mandanten und Standorte im Customer-Modul – alle sind als EntityStructures definiert und teilen dadurch dieselben Fähigkeiten.