Stored procedures versus visuele workflows: waar logica thuishoort

Wat deze beslissing echt betekent

Bedrijfslogica is de verzameling regels die bepaalt wat is toegestaan, wat er daarna gebeurt en wat het systeem moet doen wanneer echte mensen het gebruiken. Het is niet de data zelf. Het is het gedrag: wie wat kan doen, onder welke voorwaarden en met welke neveneffecten.

Dus het debat over stored procedures versus visuele workflows gaat eigenlijk over waar deze regels moeten wonen zodat ze gemakkelijk te veranderen zijn, moeilijk kapot te maken en duidelijk voor de mensen die het proces beheren.

De meeste teams eindigen met drie mogelijke “huizen” voor logica:

• In de database (stored procedures, triggers, constraints): regels draaien dicht bij de data. Dit kan snel en consistent zijn, maar lastiger voor niet-database-specialisten om te wijzigen.
• In visuele workflows (drag-and-drop process builders): regels worden uitgedrukt als stappen en beslissingen. Dit is vaak makkelijker te lezen, te reviewen en aan te passen als het proces verandert.
• In aangepaste code (services, apps, scripts): regels zijn geschreven in een programmeertaal. Dit geeft maximale flexibiliteit, maar wijzigingen vereisen meestal meer engineeringdiscipline en testen.

De keuze beïnvloedt de dagelijkse snelheid en het onderhoud op lange termijn. Zet logica op de verkeerde plek en je krijgt trage oplevering (elke wijziging heeft de ene persoon nodig die de database kent), meer fouten (regels gedupliceerd op meerdere plekken) en pijnlijk debuggen (niemand weet waarom een record werd afgewezen).

De meeste systemen bevatten verschillende soorten bedrijfslogica. Veelvoorkomende voorbeelden zijn validatie (verplichte velden, toegestane bereiken), goedkeuringen, prijsstelling en kortingen, notificaties en toegangsregels.

Een praktische manier om erover na te denken: de database is goed in het beschermen van data-integriteit, visuele workflows zijn goed in het uitdrukken van bedrijfsprocessen en aangepaste code is handig wanneer de regel te uniek of te complex is om netjes te modelleren. Platforms zoals AppMaster zitten sterk in het midden: je kunt data modelleren en vervolgens het proces als leesbare visuele logica implementeren zonder regels over veel apps te verspreiden.

De criteria: waar je voor optimaliseert

Dit is niet echt een smaakvraag. Het gaat over wat je probeert te beschermen: de data, de mensen die het systeem veranderen en de snelheid van verandering.

De uitkomsten die het meest tellen

Noem de belangrijkste uitkomsten voor je project. De meeste teams balanceren een mix van deze:

• Correctheid: regels moeten elke keer hetzelfde draaien, zelfs onder load.
• Helderheid: iemand nieuw moet begrijpen wat er gebeurt zonder te moeten raden.
• Snelheid: de logica moet snel draaien en dicht bij de data zijn wanneer nodig.
• Controleerbaarheid: je moet kunnen aantonen wie wat veranderde en wanneer het draaide.
• Wijzigingsfrequentie: je verwacht dat requirements wekelijks veranderen, niet jaarlijks.

Je maximaliseert zelden alle vijf. Logica dichter bij de database zetten kan correctheid en snelheid verbeteren, maar het kan de helderheid verminderen voor mensen die niet in SQL leven.

Wie zal de logica aanpassen (en hoe vaak)

Wees eerlijk over wie wijzigingen dagelijk doet. Een regel die ops elke week moet aanpassen, moet geen DBA vereisen om een stored procedure te deployen. Tegelijkertijd moet een regel die geld raakt niet zonder review bewerkbaar zijn.

Denk in termen van wijzigingsfrictie. Als requirements vaak veranderen, wil je een plek waar updates veilig, zichtbaar en snel te deployen zijn. Visuele workflowtools (bijvoorbeeld AppMaster’s Business Process Editor) kunnen goed werken wanneer business-eigenaren en engineers moeten samenwerken aan logica zonder laag-niveau code te bewerken. Als wijzigingen zeldzaam zijn en de regel kritisch is, is hogere frictie acceptabel.

Een snelle manier om eigenaarschap te testen:

• Wie krijgt een alert als het om 2 uur ’s nachts fout gaat?
• Hoe snel moet je een regel patchen?
• Hebben wijzigingen goedkeuringen of een papieren spoor nodig?
• Zullen meerdere apps van dezelfde regel afhankelijk zijn?
• Is de logica vooral data-vormend of bedrijfsbeslissend?

Noteer beperkingen vroeg. Sommige industrieën vereisen strikte toegangscontrole, scheiding van taken of gedetailleerde logs. Denk ook aan data-toegangsbeperkingen: als slechts bepaalde services bepaalde velden mogen zien, beïnvloedt dat waar logica veilig kan draaien.

Wanneer logica in stored procedures hoort

Stored procedures zijn stukjes logica die binnen de database draaien. In PostgreSQL worden ze geschreven in SQL (en soms in een databasespecifieke taal zoals PL/pgSQL). In plaats van dat je app rijen haalt, loopjes doet en wijzigingen terugschrijft, doet de database het werk precies waar de data woont.

Een goede vuistregel is simpel: zet logica in de database wanneer de hoofdtaak het beschermen van data en bulkdatawerk is, niet het coördineren van mensen of systemen.

Waar stored procedures uitblinken

Stored procedures passen goed bij regels die altijd waar moeten zijn, ongeacht welke app of integratie de database aanraakt. Denk aan vangrails die slechte data buiten houden.

Ze zijn ook sterk bij set-gebaseerde updates, waar één statement duizenden rijen veilig en snel kan bijwerken. Simpele berekeningen die puur over data gaan, zoals het berekenen van totalen of het toepassen van een vaste kortingsformule, kunnen hier ook leven als het roundtrips vermindert en resultaten consistent houdt.

Voorbeeld: wanneer een bestelling als paid wordt gemarkeerd, kan een procedure atomair de orderstatus bijwerken, de voorraad verminderen en een auditregel schrijven. Als een stap faalt, rolt de hele wijziging terug.

Wanneer stored procedures riskant worden

Stored procedures kunnen lastiger zijn om te testen en te versioneren dan applicatiecode, vooral als je team databasewijzigingen niet als echte releases behandelt. Logica kan ook “verborgen” raken voor de app, waardoor er coupling ontstaat die je pas later ontdekt.

Debuggen wordt ook moeilijker. Fouten kunnen naar voren komen als databaseberichten met minder context over wat de gebruiker deed. Nieuwe teamleden kunnen worstelen omdat regels verdeeld zijn over de app en de database, en databaselogica is gemakkelijk te missen tijdens onboarding.

Als je een visueel hulpmiddel voor de meeste logica gebruikt, reserveer stored procedures voor de kleine, stabiele kern die dicht bij de data moet draaien. Houd alles anders daar waar het makkelijker is te lezen, traceren en veranderen.

Wanneer logica het beste in visuele workflows past

Visuele workflows zijn stap-voor-stap processlogica die je kunt lezen als een checklist: wanneer iets gebeurt, voer deze acties in deze volgorde uit, met duidelijke beslispunten. Ze gaan minder over zware berekening en meer over hoe werk door mensen, systemen en tijd beweegt.

Ze blinken uit wanneer je geeft om gedeeld begrip. Als product, ops, support en engineering het allemaal eens moeten zijn over hoe een proces werkt, maakt een visuele workflow de regels zichtbaar. Die zichtbaarheid is vaak het verschil tussen “het systeem is kapot” en “het proces veranderde vorige week.”

Visuele workflows passen meestal goed bij goedkeuringen en reviews, routering, notificaties en herinneringen, getimde stappen (wacht 2 dagen, escaleer dan) en integraties (roep Stripe aan, stuur een bericht, werk een CRM bij).

Voorbeeld: een klant vraagt om een terugbetaling. De workflow controleert de leeftijd van de bestelling, stuurt naar een manager als het boven een drempel is, meldt finance bij goedkeuring en stuurt de klant een update. Elke stap is makkelijk aan te wijzen en te bespreken in gewone taal, wat stakeholders helpt goed te keuren en nieuwe teamleden helpt het “waarom” te begrijpen.

Tools zoals AppMaster’s Business Process Editor zijn gebouwd voor dit soort logica: je ziet het pad, de voorwaarden en de neveneffecten (berichten, API-calls, statuswijzigingen) zonder in databas scripts te graven.

Om te voorkomen dat workflows in spaghetti veranderen, houd ze klein en leesbaar. Geef elke workflow één uitkomst, gebruik duidelijke namen voor stappen en takken, beperk diepe geneste beslissingen en log belangrijke keuzes zodat je later kunt beantwoorden “waarom gebeurde dit?”.

Wanneer een workflow complexe data-berekeningen begint te doen of veel tabellen aanraakt, is dat meestal een signaal om een deel van de logica elders te plaatsen. Visuele workflows werken het beste als dirigent, niet als het hele orkest.

Wanneer aangepaste code het juiste middel is

Aangepaste code is logica die je schrijft en onderhoudt als software: functies, services of kleine libraries die onderdeel zijn van je app. Het is de meest flexibele optie, en daarom moet je hem doelbewust gebruiken, niet standaard.

Aangepaste code verdient zijn plek wanneer de logica moeilijk veilig te uiten is in een databaseprocedure of een drag-en-drop-workflow. Als je tools krom trekt om het probleem passend te maken, is code vaak duidelijker en makkelijker correct te houden.

Sterke signalen om voor code te kiezen:

• Het probleem is algoritmisch (prijsregels, routeplanning, scoring, matching, fraud checks) en heeft veel randgevallen.
• Je hebt een ongebruikelijke integratie nodig (een partner-API met vreemde authenticatie, complexe retries, strikte idempotency regels).
• Prestaties zijn gevoelig (hoogvolume verwerking, zware berekeningen, zorgvuldige caching) en je hebt strakke controle nodig.
• Je moet dezelfde logica op meerdere plekken delen (web, mobiel, batchjobs) zonder te kopiëren.
• Je hebt sterke automatische tests rond de logica nodig omdat fouten duur zijn.

Code maakt ook eigenaarschap duidelijker. Een team kan verantwoordelijk zijn voor het reviewen van wijzigingen, het groen houden van tests en het documenteren van gedrag. Dat is beter dan “het leeft in drie workflows en niemand weet welke als eerste draait.”

Voorbeeld: een refund decision engine die kijkt naar ordergeschiedenis, fraudesignalen, verzendstatus en tijdvensters. Je kunt de goedkeuringsstappen in een visuele workflow houden, maar de beslissing zelf is vaak beter als code met unit tests en versiebeheer.

De kosten zijn reëel. Aangepaste code vereist engineeringtijd, reviews en doorlopend onderhoud. Wijzigingen kunnen langer duren dan het aanpassen van een workflow, en je hebt een releaseproces nodig. AppMaster kan verminderen hoeveel code je nodig hebt door veelvoorkomende delen met visuele logica en modules te dekken, terwijl teams toch broncode kunnen exporteren en uitbreiden waar echt nodig.

Een herbruikbaar stappenplan

Teams slaan vaak het meest nuttige deel over: de regel duidelijk opschrijven en dan een thuis kiezen dat past bij het gedrag van de regel.

Gebruik dit raamwerk wanneer nieuwe logica verschijnt:

• Schrijf de regel in één zin, en label hem. Als het over geldige data gaat (constraints, uniekheid, totalen die moeten kloppen), is het een dataregel. Als het over stappen en overdrachten gaat (goedkeuringen, wachttijden, notificaties), is het een procesregel. Als het zware wiskunde of complexe transformaties is, is het een computatieregel.
• Vraag wie het bewerkt en hoe vaak. Als niet-technische mensen het wekelijks moeten aanpassen, begraaf het dan niet in SQL of een code-release. Als het zelden verandert en elke keer moet worden afgedwongen, is de database een sterkere kandidaat.
• Check faalimpact en het auditspoor dat je nodig hebt. Als een fout geldverlies, complianceproblemen of moeilijk te herstellen data kan veroorzaken, kies dan een plek met duidelijke logging en strakke controle.
• Kies de locatie en definieer de grens. Wees expliciet over inputs, outputs en fouten. Voorbeeld: “Gegeven een order_id, retourneer allowed_refund_amount of een duidelijke reason code.” Die grens voorkomt dat logica overal heen lekt.
• Houd één laag voornamelijk dun. Bepaal wat vooral “dom” moet blijven zodat je regels niet dupliceert. Veelvoorkomende keuzes zijn: houd de database dun (alleen dataintegriteit), houd workflows dun (alleen orkestratie) of houd code dun (alleen glue).

Vuistregel: zet dataregels het dichtst bij de data, zet procesregels in een workflowtool en zet computatieregels waar ze het makkelijkst te testen en te versioneren zijn.

Als je een platform zoals AppMaster gebruikt, kun je de database als vangrails behandelen (tabellen, relaties, basisconstraints) en de visuele Business Process Editor gebruiken voor het “wie doet wat daarna”-deel, terwijl je aangepaste code reserveert voor de weinige gevallen die het echt nodig hebben.

Veelgemaakte fouten die systemen rommelig maken

Rommelige systemen ontstaan zelden door één slechte keuze. Ze ontstaan wanneer logica verspreid, verborgen of gekopieerd raakt totdat niemand zeker weet wat het systeem daadwerkelijk doet.

Duplicatie is het klassieke probleem: dezelfde regel bestaat op twee plekken, maar ze groeien uit elkaar. Voorbeeld: de database weigert restituties boven €500 tenzij er een goedkeuringsrecord is, maar een workflow stuurt nog steeds de terugbetaling naar betalingen omdat hij een andere limiet gebruikt. Beide “werken” totdat het eerste echte randgeval zich voordoet, dan heeft support een mysteriebug.

Verborgen regels zijn de volgende. Triggers, stored procedures en snelle fixes in de database kunnen onzichtbaar zijn voor mensen die de UI of workflows bouwen. Als de regel niet gedocumenteerd is bij de workflow of API die ervan afhankelijk is, worden wijzigingen giswerk en testing een kwestie van trial-and-error.

Overbeladen workflows creëren weer een ander soort rommel. Een lange drag-and-drop-keten met tientallen takken wordt een fragiel ding waar niemand aan wil komen. In tools zoals AppMaster is het makkelijk om blokken te blijven toevoegen omdat het snel gaat, maar snelheid vandaag kan verwarring later betekenen als de workflow geen duidelijke grenzen heeft.

Twee tegenovergestelde “te veel”-fouten veroorzaken langdurige pijn:

• Te veel in de database: elke beleidswijziging wordt een migratieproject en kleine producttweaks wachten op database-releases.
• Te veel in appcode: basisdatregels (verplichte velden, toegestane statussen, unieke constraints) worden vergeten en slechte data glipt binnen via imports, admin-tools of toekomstige integraties.

Een eenvoudige gewoonte voorkomt het meeste: houd elke regel in één primaire plek en noteer waar hij leeft en waarom. Als je niet binnen 10 seconden kunt antwoorden op “waar wordt dit afgedwongen?”, betaal je al de rommelbelasting.

Snelle checks: beslis in 2 minuten

Je kiest waar een regel het makkelijkst correct, zichtbaar en wijzigbaar blijft.

Begin met één vraag: gaat deze regel over datacorrectheid, wat betekent dat hij nooit mag worden omzeild? Zo ja, zet hem dichter bij de database. Gaat het over stappen, goedkeuringen of notificaties, houd hem dan dichter bij de workflowlaag.

Een snelle checklist:

• Handhaaft het datacorrectheid (voorkomen van negatieve voorraad, blokkeren van dubbele “actieve” records)? Neig naar database.
• Raakt het veel tabellen en heeft het set-gebaseerde updates nodig (veel rijen tegelijk)? Neig naar database.
• Heeft het een duidelijk, menselijk leesbaar auditspoor nodig van wie goedkeurde wat en wanneer? Neig naar workflow.
• Moeten niet-engineers het wekelijks of maandelijks wijzigen? Neig naar workflow.
• Roept het externe services aan (betalingen, messaging, AI)? Neig naar applicatie of workflow, niet de database.

Denk nu aan falen. Een regel die kan falen moet dat doen op een manier waarop mensen kunnen herstellen.

Als je veilige retries en duidelijke foutmeldingen nodig hebt, geef de voorkeur aan een orkestratielaag waar je state kunt volgen en exceptions stap voor stap kunt afhandelen. Visuele workflowtools maken dit vaak makkelijker omdat elke stap expliciet is en gelogd kan worden.

Een praktisch beslissingsmiddel:

• Als het systeem correct moet blijven ook als iemand later een nieuwe app schrijft, handhaaf het in de database.
• Als het proces bedoeld is om door ops-teams te worden gelezen en ger reviewed, houd het in een visuele workflow.
• Als het complexe integraties, zware berekeningen of speciale libraries betreft, gebruik aangepaste code.

Voorbeeld: “Refund amount cannot exceed original payment” is correctheid, dus handhaaf het dicht bij de data. “Refunds over €500 require manager approval and then send a Telegram message” is een workflow. In AppMaster past die goed in de Business Process Editor, terwijl strikte constraints in het datamodel blijven.

Voorbeeldscenario: restituties met goedkeuringen

Een veelvoorkomend praktijkgeval is een terugbetaling die boven een bepaald bedrag managergoedkeuring nodig heeft, plus notificaties en een duidelijk auditspoor.

Begin met één bron van waarheid: één enkele Refund-record met bedragen en een duidelijk statusveld (bijvoorbeeld: requested, needs_approval, approved, rejected, processing, paid, failed). Elk deel van het systeem moet deze velden lezen en schrijven, in plaats van parallelle statussen op verschillende plekken te houden.

Wat in de database hoort

Zet regels die geld en dataconsistentie beschermen zo dicht mogelijk bij de data.

Gebruik constraints (en soms een stored procedure) om te waarborgen dat je niet meer terugbetaalt dan het vastgelegde betaalde bedrag, geen bestelling terugbetaalt die al volledig is terugbetaald, niet twee actieve terugbetalingsverzoeken voor dezelfde bestelling aanmaakt, of sleutelbedragen verandert nadat de terugbetaling is goedgekeurd.

Houd ook de atomische update hier: wanneer een refundverzoek wordt aangemaakt, schrijf de Refund-rij en werk de Order-totals bij in één transactie. Als een van beide writes faalt, mag er niets gedeeltelijk geüpdatet zijn.

Wat het beste in een visuele workflow past

Goedkeuringsstappen zijn proces, geen databeveiliging. Een visuele workflow is een goede plek om het verzoek naar de juiste manager te routeren, te wachten op een beslissing, de status bij te werken, herinneringen te sturen en de verzoeker te informeren.

Een eenvoudige flow kan zijn: create request -> als bedrag boven limiet, zet status op needs_approval -> notify manager -> als goedgekeurd, zet op approved -> notify requester -> als geen reactie binnen 24 uur, stuur een herinnering.

In een tool zoals AppMaster past dit netjes in een Business Process die reageert op statuswijzigingen en e-mail, SMS of Telegram-berichten triggert.

Wat aangepaste code zou moeten doen

Betaalproviders hebben randgevallen die niet altijd netjes in regels of drag-and-drop-stappen passen. Houd providerspecifieke logica in aangepaste code, zoals gedeeltelijke refunds met fees of multi-capture betalingen, webhookreconciliatie (provider zegt “paid” maar jouw app zegt “processing”) en idempotency- en retryafhandeling wanneer de provider time-outs geeft.

Belangrijk is dat aangepaste code geen eigen statussen uitvindt. Het leest de Refund-record, voert de provideractie uit en schrijft vervolgens de volgende status en bevestigde bedragen terug zodat de database het grootboek blijft dat iedereen vertrouwt.

Volgende stappen: zorg dat de keuze blijft bestaan

Een goede beslissing helpt alleen als hij over zes maanden nog steeds klopt. Het doel is om je keuze “waar hoort deze logica te wonen?” eenvoudig zichtbaar, makkelijk te testen en moeilijk per ongeluk te omzeilen te maken.

Maak een eenvoudige logica-map: een korte lijst van je sleutelregels en het huis dat je voor elk koos. Houd het kort en werk het bij wanneer een regel verandert. Neem de regelnaam op, waar hij leeft (database, workflow, aangepaste code), waarom (één zin), wat hij leest en schrijft en wie wijzigingen goedkeurt.

Schrijf grenzen op als ononderhandelbare waarborgen die je systeem beschermen als mensen later features toevoegen. Een nuttig format is: “De database garandeert X” en “Workflows handhaven Y.” Bijvoorbeeld: de database garandeert dat een refundrecord niet kan bestaan zonder een order, terwijl de workflow afdwingt dat restituties boven €500 managergoedkeuring vereisen.

Plan testen voordat je iets verandert. Je hebt geen groot testplan nodig, slechts enkele gevallen die je elke keer opnieuw draait als de regel verandert:

• Happy path (verwachte input, verwacht resultaat)
• Faalpad (ontbrekende data, ongeldige status, dubbel verzoek)
• Concurrency (twee mensen die tegelijk dezelfde actie triggeren)
• Security (een gebruiker die stappen overslaat of direct een endpoint aanroept)

Stel ook eigenaarschap en reviewregels vast. Bepaal wie stored procedures mag bewerken, wie workflows mag aanpassen en wat peer review vereist. Daar blijft veel systemen gezond of gaat het mis omdat “niemand weet waarom dit werkt”.

Als je drag-en-drop-workflows wilt zonder echte backend-structuur op te geven, kan een platform zoals AppMaster (appmaster.io) een praktisch middenpad zijn: modelleer je data, druk het proces uit in de Business Process Editor en regenereer en deploy wanneer requirements veranderen.

Kies één regel met hoge impact, map hem, voeg de grenzen toe en schrijf drie testcases. Die ene gewoonte voorkomt de meeste logicaspreiding.