Mendix binnen de enterprise omgeving – #1
Leestijd: ± 8 minuten
De realiteit van groeiende Mendix-applicaties
Vrijwel elke Mendix-app begint hetzelfde: klein, overzichtelijk en met een duidelijke scope. Een paar entiteiten, een handvol microflows en korte lijnen binnen het team. In die fase voelt Mendix precies zoals het bedoeld is: snel, productief en prettig om mee te werken.
Succes verandert dat beeld. Meer gebruikers betekent meer wensen. Meer wensen leiden tot meer functionaliteit, extra entiteiten en nieuwe microflows. Teams groeien, releases volgen elkaar sneller op en wat ooit een compacte applicatie was, wordt langzaam een volwassen landschap.
Tot zover niets bijzonders: dit is wat groei doet. De echte problemen ontstaan meestal niet tijdens de eerste bouwfase, maar daarna. Wanneer de applicatie live is en kleine wijzigingen onderdeel worden van reguliere releases.
In die fase duiken herkenbare symptomen op. Een commit heeft onverwachte side-effects. Een validatie blijkt ‘ergens anders’ te zitten dan je dacht. Microflows doen net iets meer dan comfortabel voelt. En sommige bugs laten zich pas zien in productie, alsof ze een uitgesproken hekel hebben aan testomgevingen.
Dit zijn geen uitzonderingen en ook geen tekenen van slecht ontwikkelwerk. Het zijn typische gevolgen van een applicatie die is gegroeid zonder expliciet stil te staan bij verantwoordelijkheden, transacties en onderlinge afhankelijkheden. Of anders gezegd: de complexiteit is niet ineens ontstaan, maar langzaam binnengeslopen.
Commit Scope is ontstaan als het antwoord van MxBlue op precies deze fase van volwassenwording. Niet om de snelheid van Mendix te beperken, maar om ook bij verdere groei grip te houden op gedrag, data en kwaliteit.
Waarom Commit Scope nodig is in groeiende Mendix-applicaties
Commit Scope is ontstaan vanuit één centrale vraag: hoe houd je een groeiende Mendix-app beheersbaar zonder steeds zwaarder te leunen op discipline en afspraken?
Wanneer een applicatie volwassen wordt, zien we in de praktijk steeds dezelfde drie kwaliteitsdoelen onder druk komen te staan: data-integriteit, onderhoudbaarheid en testbaarheid. Niet als abstracte architectuurprincipes, maar als concrete problemen die zich manifesteren in het dagelijks ontwikkelwerk.
Data-integriteit is vaak het eerste signaal dat er iets begint te schuiven. Naarmate functionaliteit groeit, wordt het minder vanzelfsprekend welke objecten functioneel bij elkaar horen en samen gewijzigd moeten worden. Kleine wijzigingen in vervolgreleases kunnen dan onverwachte regressies veroorzaken, met als gevolg data die technisch correct is opgeslagen, maar functioneel niet meer klopt. Juist deze subtiele inconsistenties zijn verraderlijk, omdat ze zich vaak pas later laten zien en lastig te herstellen zijn.
Onderhoudbaarheid volgt meestal niet veel later. Microflows groeien mee met de applicatie en nemen steeds meer verantwoordelijkheden op zich, waardoor logica voor interactie, validatie en businessregels met elkaar verweven raakt. De code blijft functioneren, maar wordt steeds lastiger te lezen, te reviewen en veilig aan te passen.
Testbaarheid staat zelden los van deze twee problemen. Impliciete commits, verborgen validaties en side-effects in UI-flows maken het opzetten van betrouwbare automatische tests moeizaam. Tests falen soms wel en soms niet, of missen precies de scenario’s die in productie wél misgaan. Het gevolg is dat vertrouwen opnieuw verschuift naar handmatige controles en voorzichtigheid, wat de doorontwikkeling verder afremt.
Deze problemen versterken elkaar en maken elke volgende wijziging moeilijker dan de vorige. Voor je het weet zit je in een cirkel die zichzelf netjes in stand houdt, met als enige echte innovatie dat alles steeds meer tijd kost. Commit Scope is bedoeld om deze cirkel te doorbreken door expliciete structuur aan te brengen rond transacties, validatie en verantwoordelijkheden.
Commit Scope vindt zijn oorsprong in het Menditect Testability Framework. Niet als kopie, maar als onze interpretatie van het idee dat kwaliteit een ontwerpbeslissing is, geen correctiemechanisme.
De drie kernprincipes van Commit Scope
De problemen die we hiervoor beschreven hebben geen exotische oplossingen nodig. Ze vragen vooral om expliciete keuzes. Commit Scope is opgebouwd rond een klein aantal principes die samen zorgen voor voorspelbaar gedrag, zonder de flexibiliteit van Mendix onnodig te beperken.
1. Expliciet bepalen wat samen hoort
Het eerste principe is misschien wel het belangrijkste: vóórdat je iets commit, bepaal je expliciet welke objecten functioneel bij elkaar horen, i.e. de Commit Scope. Niet vanuit een technisch perspectief, maar vanuit de businesslogica van de applicatie.
In veel applicaties gebeurt dit impliciet. Een microflow raakt meerdere entiteiten aan, commits vinden verspreid plaats en de onderlinge samenhang ontstaat vooral door toeval en volgorde. Commit Scope draait dit om. Je definieert bewust welke entiteiten samen één consistente wijziging vormen en dus ook samen gecommit moeten worden.
Typische voorbeelden zijn een order met bijbehorende orderregels, een patiënt met metingen of een contract met zijn versies. Door deze samenhang expliciet te maken, voorkom je dat de database tijdelijk of permanent in een functioneel ongeldige toestand terechtkomt.
2. Valideren vóórdat je commit
Het tweede principe volgt daar logisch uit. Als je weet wat je samen gaat committen, kun je ook volledig valideren vóórdat er iets naar de database wordt geschreven.
In veel Mendix-applicaties is validatie verspreid geraakt: een deel zit in de UI, een deel in microflows en een deel in entity events. Dat werkt, totdat het niet meer werkt. Het moment waarop je beseft dat ‘ergens’ blijkbaar ook een architectuurkeuze was. Foutmeldingen worden onvoorspelbaar en tests krijgen te maken met verborgen regels die alleen onder specifieke omstandigheden actief worden.
Commit Scope maakt validatie expliciet en deterministisch. Alles wat moet gelden voor een consistente commit wordt vooraf gecontroleerd. Pas als de volledige set objecten geldig is, volgt de database-transactie. Dat geeft controle over foutafhandeling en maakt validatielogica vindbaar, herbruikbaar en testbaar.
3. Scheiding van verantwoordelijkheden
Het derde principe is de scheiding van verantwoordelijkheden. Niet als theoretische exercitie, maar als praktisch middel om complexiteit te beperken.
Commit Scope hanteert een duidelijke gelaagdheid. Interface-logica is verantwoordelijk voor interactie en ingangen. De proceslaag orkestreert de use case en bepaalt de commit scope. Entiteitslogica bevat validaties, database transacties, en businessregels. Elke laag heeft een eigen rol en doet zo min mogelijk meer dan dat.
Microflows worden kleiner en voorspelbaarder. Logica wordt herbruikbaar. Of anders gezegd: de applicatie wordt niet per se simpeler, maar wel begrijpelijker.
Waar de uitdagingen liggen
Commit Scope is een bewuste ontwerpkeuze en daarmee ook een afbakening. Het patroon optimaliseert expliciet voor voorspelbaarheid, data‑integriteit en onderhoudbaarheid, en niet voor maximale doorvoer in alle situaties.
Die keuze vraagt om een andere manier van werken. Structuur trekt zich vaak weinig aan van ons verlangen naar snelheid. Door expliciete commitmomenten, gecentraliseerde validatie en striktere structuur wijkt Commit Scope af van gangbare Mendix‑patronen zoals uitgebreide entity events of impliciet gedrag verspreid over microflows. Dat kan in het begin ongemakkelijk voelen, maar het ongemak is nog groter bij bugs in productie.
Dat maakt Commit Scope geen vanzelfsprekende keuze in elke situatie. Het patroon past vooral goed bij business‑gedreven entiteiten en use‑cases met duidelijke transacties, waar inconsistentie directe impact heeft en stabiliteit belangrijker is dan pure snelheid. Minder geschikt is het patroon bij technische of ondersteunende entiteiten, zoals logging, staging of afgeleide data, en bij hoog‑volume of performance‑kritische paden zoals bulk imports of grote synchronisaties. In die scenario’s introduceert de extra structuur vooral overhead, zonder voldoende toegevoegde waarde.
De kern van de afweging is eenvoudig. Wat bij businesslogica een feature is, namelijk expliciete validatie en controle, kan bij throughput‑gedreven scenario’s juist een nadeel worden. Commit Scope is daarmee geen dogma, maar een gereedschap dat bewust en selectief moet worden ingezet.
Voor wie is Commit Scope bedoeld?
Commit Scope is geen universeel patroon, maar vooral relevant wanneer applicaties en teams een bepaalde schaal bereiken. Vaak nadat een paar kleine wijzigingen hebben laten zien dat ‘klein’ een relatief begrip is.
Voor Mendix-developers die verder willen kijken dan “het werkt nu”, biedt Commit Scope een manier om structureel grip te houden op groeiende complexiteit. IT-projectleiders krijgen meer voorspelbaarheid in kwaliteit en minder afhankelijkheid van individuele kennis of ervaring. En voor Product Owners betekent het minder regressies en meer vertrouwen bij het releasen van nieuwe functionaliteit.
Of anders gezegd: Commit Scope is vooral interessant wanneer stabiliteit, onderhoudbaarheid en voorspelbaar gedrag belangrijker worden dan maximale snelheid in elke individuele wijziging.
Conclusie
Commit Scope draait niet om hoe je commit, maar om wanneer je besluit dat iets klopt. En juist die beslissing wil je niet impliciet laten ontstaan.
Het patroon is daarmee geen versneller. Het is een stabilisator. En die heb je vooral nodig wanneer het tempo omhoog gaat, de impact toeneemt en kwaliteit geen toeval meer mag zijn.
Auteur: Stephan Wolbers – Head of Technology & Innovation MxBlue | SUPERP
