Der Aufbau eines Hauptbuchs:
Vier Entitäten reichen aus.

Die ersten sechs Monate bei „VenduSys“ haben wir damit verbracht, alles zu modellieren. Im vierten Monat hatten wir siebzehn Entitäten, acht Verknüpfungstabellen, drei „Kontext“-Objekte, die niemand so recht definieren konnte, und ein Berechtigungsmodell, dessen Erklärung zwanzig Minuten dauerte. Ein Klassiker.

Dann haben wir das verworfen und sind von einer Frage ausgegangen: Was ist die kleinste Menge von Entitäten, mit der sich alle für uns relevanten Geschäftsmodelle abbilden lassen?

Die Antwort lautete schließlich vier.

Party

Eine Person, eine Organisation oder ein Vertreter. Käufer, Verkäufer, Betreiber, Partner – allesamt Projektionen desselben Datensatzes. Der Unterschied zwischen „Käufer“ und „Verkäufer“ ist kein Typ, sondern eine Rolle innerhalb einer Transaktion. Ein Käufer in einem Schritt ist im nächsten Schritt ein Verkäufer.

Sobald man das akzeptiert, wird Identität eher zu einem Graphenproblem als zu einem Typisierungsproblem. KYB, KYC, Rollen, Audit, Auszahlungskonfiguration – alles hängt mit demselben Knoten zusammen.

Ding

Alles, was angeboten wird oder im Besitz ist. Produkte, Lizenzen, Dienstleistungen, Abonnements, Vermögenswerte, Zeit. Varianten und Bundles sind darüber hinausgehende Ausprägungen – eine SKU ist ein „Ding“ in einer bestimmten Form, ein Abonnementmodell ist ein „Ding“ mit einer zeitlichen Dimension, eine Dienstleistungsstunde ist ein „Ding“ mit einer Kapazitätsdimension.

Die meisten E-Commerce-Stacks modellieren diese als separate Einheiten (Produkt, Tarif, Dienstleistung, Vermögenswert) und verbringen dann Jahre damit, die Lücken zu schließen. Wenn man sie hingegen als eine Einheit mit Attributen betrachtet – unbefristet oder zeitlich begrenzt, physisch oder digital, übertragbar oder nicht –, lässt sich ein überraschend großer Teil der Komplexität reduzieren.

Verschieben

Ein Vorgang, bei dem Werte oder Rechte zwischen Parteien übertragen werden. Bestellungen, Rücksendungen, Verlängerungen, Übertragungen, Rückerstattungen, Streitfälle – all dies sind Vorgänge. Ein Vorgang umfasst einen Zahler, einen Zahlungsempfänger, einen Gegenstand (oder eine Gruppe von Gegenständen), einen Betrag und einen Status.

Wenn man „Bestellung“ und „Rückerstattung“ als Objekte derselben Art – mit unterschiedlichen Vorzeichen – modelliert, lässt sich eine ganze Kategorie von Fehlern vermeiden.

Eintrag

Ein Eintrag im Hauptbuch nach dem Prinzip der doppelten Buchführung. Jede Transaktion erzeugt Buchungen; Berichte und Salden leiten sich deterministisch daraus ab. Dies ist die wichtigste Einheit im System – und diejenige, die die meisten Handelsplattformen verbergen.

Wenn Ihre Plattform ein System zur Erfassung von Geldtransaktionen ist, Ihr Hauptbuch jedoch nur eine nachträgliche Ergänzung darstellt, dann ist Ihre Plattform ein System der „plausiblen Abstreitbarkeit“.

Warum das funktioniert

Der Clou sind nicht die vier Unternehmen. Der Clou ist das, was sie einem vorenthalten:

• Keine gesonderten Auftragsarten „Marktplatzauftrag“ und „Direktauftrag“
• Es gibt kein separates „Abonnement“ und keinen „Einmalkauf“ – beides sind Abfolgen von Schritten
• Es gibt kein separates „Portemonnaie“ – der Kontostand ist die Summe aller Buchungen auf einem Konto
• Keine separate „Rückerstattungs-Engine“ – eine Rückerstattung ist ein Stornovorgang mit entsprechenden Stornobuchungen
• Es gibt kein separates „Partner-Hauptbuch“ – Auszahlungen an Partner werden einfach als Buchungen auf den Partnerkonten erfasst

Die Form im Code

Grob gesagt, in TypeScript:

type Party = { id; kind: 'person' | 'org' | 'machine'; profile; trust };
type Thing = { id; kind; attrs; rights?; meter? };
type Move  = { id; kind; from: PartyId; to: PartyId; thing: ThingId[];
               at; state; reverses?: MoveId };
type Entry = { id; account; move: MoveId;
               side: 'debit' | 'credit'; amount; ccy };

Alles andere – Bestellungen, Rechnungen, Abonnements, Partnerprogramme, Marktplätze – ist ein Workflow, der diese Elemente miteinander verknüpft. Die Workflow-Bibliothek ist Thema eines anderen Beitrags.

Was wir aufgegeben haben

Mal ganz ehrlich: Es geht um die Verständlichkeit. „Auftrag“ und „Abonnement“ sind nützliche Begriffe im Gespräch mit Nicht-Ingenieuren. Wir behalten sie als Projektionen in der API-Oberfläche bei – aber im Hintergrund sind sie Abfolgen von Vorgängen. Diese Diskrepanz ist der Preis, den wir dafür zahlen.

Im Gegenzug haben wir ein System erhalten, das nicht zusammenbricht, wenn eine neue Form hinzukommt. Wir werden wissen, dass wir das Modell richtig umgesetzt haben, wenn wir niemals eine fünfte Entität hinzufügen müssen. Fragen Sie uns in drei Jahren noch einmal.

Edwin Korver is the founder and systems architect behind VenduSys and RoundMap®. His work focuses on regenerative business, value orchestration, and the systems that help organizations move from extraction toward shared value and healthier ecosystems.