De eerste zes maanden van VenduSys hebben we alles in modellen uitgewerkt. Tegen de vierde maand hadden we zeventien entiteiten, acht koppelingstabellen, drie „context”-objecten die niemand echt kon definiëren, en een machtigingsmodel dat twintig minuten kostte om uit te leggen. Typisch.
Vervolgens hebben we dat idee terzijde geschoven en zijn we uitgegaan van een vraag: wat is de kleinste verzameling entiteiten waarmee we elke commerciële vorm kunnen modelleren die voor ons van belang is?
Het antwoord bleek vier te zijn.
Feest
Een persoon, organisatie of tussenpersoon. Kopers, verkopers, exploitanten, partners — allemaal verschillende benamingen voor hetzelfde record. Het verschil tussen „koper” en „verkoper” is geen type, maar een rol in een transactie. Een koper in de ene transactie is een verkoper in de volgende.
Zodra je dat accepteert, wordt identiteit een grafiekprobleem in plaats van een typeprobleem. KYB, KYC, rollen, audits, uitbetalingsinstellingen — ze hangen allemaal aan hetzelfde knooppunt.
Ding
Alles wat wordt aangeboden of in bezit is. Producten, licenties, diensten, abonnementen, activa, tijd. Varianten en bundels zijn daar bovenop geplaatste projecties — een SKU is een ‘ding’ in een bepaalde vorm, een abonnement is een ‘ding’ met een tijdsdimensie, een dienstuur is een ‘ding’ met een capaciteitsdimensie.
De meeste e-commerceplatforms modelleren deze als afzonderlijke entiteiten (Product, Abonnement, Dienst, Activa) en zijn vervolgens jarenlang bezig met het dichten van de hiaten. Door ze te behandelen als één geheel met kenmerken — van onbepaalde duur of tijdgebonden, fysiek of digitaal, overdraagbaar of niet — wordt een verrassend grote hoeveelheid complexiteit weggenomen.
Verplaatsen
Een gebeurtenis waarbij waarden of rechten tussen partijen worden overgedragen. Bestellingen, retourzendingen, verlengingen, overdrachten, terugbetalingen, geschillen — dit zijn allemaal transacties. Een transactie bestaat uit een betaler, een begunstigde, een object (of een reeks objecten), een bedrag en een status.
Door „bestelling” en „terugbetaling” als hetzelfde soort object te modelleren — met verschillende tekens — wordt een hele categorie fouten uitgesloten.
Vermelding
Een regel in het grootboek volgens het dubbelboekhoudsysteem. Elke transactie genereert boekingen; rapporten en saldi worden daaruit op deterministische wijze afgeleid. Dit is het allerbelangrijkste onderdeel van het systeem, en het onderdeel dat de meeste handelsplatforms verbergen.
Als je platform een registratiesysteem voor geld is, maar je grootboek slechts een bijzaak, dan is je platform een systeem waarmee je je verantwoordelijkheid kunt ontkennen.
Waarom dit werkt
Het gaat niet om die vier entiteiten. Het gaat om wat ze je onthouden:
- Er zijn geen afzonderlijke typen „marktorder“ en „directe order“
- Er is geen onderscheid tussen „abonnement“ en „eenmalige aankoop“ — beide bestaan uit een reeks stappen
- Geen aparte „portemonnee“ — een saldo is de som van de boekingen op een rekening
- Er is geen aparte „terugbetalingsmodule“ — een terugbetaling is een terugboekingstransactie met bijbehorende tegenboekingen
- Er is geen apart „partnergrootboek“ — uitbetalingen aan partners worden gewoon als boekingen op de partnerrekeningen verwerkt
De vorm in de code
Grofweg, 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 };Al het andere — bestellingen, facturen, abonnementen, partnerprogramma’s, marktplaatsen — vormt samen een workflow. De workflowbibliotheek komt in een ander artikel aan bod.
Wat we hebben opgegeven
Eerlijk gezegd, het is wel wat onduidelijk. „Order” en „Subscription” zijn handige termen in gesprekken met niet-technici. We behouden ze als projecties in de API-interface — maar onder de motorkap zijn het reeksen van bewerkingen. Die kloof is de prijs die we ervoor betalen.
In ruil daarvoor hebben we een systeem gekregen dat niet in de war raakt als er een nieuwe vorm bijkomt. We weten dat we het model goed hebben opgezet als we nooit een vijfde entiteit hoeven toe te voegen. Vraag het ons over drie jaar nog maar eens.
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.