Wat is separation of concerns?

Je vraagt een ontwikkelaar om één veld op een factuurscherm te wijzigen, en plotseling breken drie onafhankelijke rapporten. Of je team wil een nieuwe kortingsregel toevoegen, maar niemand kan vinden waar de prijslogica zich bevindt — het is verspreid over een dozijn scripts, layouts en spreadsheetmacro's die door de jaren zijn opgebouwd. Dit is meestal geen teken van slechte ontwikkelaars; het is een teken van ontbrekende separation of concerns.

Dit artikel legt uit wat separation of concerns in de praktijk echt betekent, waarom het belangrijk is voor de totale eigendomskosten van je bedrijfssoftware, en hoe je kunt herkennen of je eigen systeem dit heeft — of het dringend nodig heeft.

Wat betekent "separation of concerns" eigenlijk?

Separation of concerns is een ontwerpprincipe dat zegt: elk onderdeel van je software moet één taak hebben, en die taak moet op één plaats leven.

In praktische termen betekent dit het onderscheid maken tussen:

• Data — wat wordt opgeslagen (klanten, bestellingen, facturen, voorraadniveaus)
• Bedrijfslogica — de regels die die data bepalen (hoe een korting wordt berekend, wanneer een bestelling mag worden verzonden, wat gebeurt er als de voorraad nul bereikt)
• Presentatie — hoe het wordt getoond aan de gebruiker (een scherm, een PDF, een mobiele weergave, een rapport)
• Integratie — hoe het systeem met andere systemen communiceert (je webshop, je boekhoudpakket, een API van een vervoerder)

Wanneer deze goed gescheiden zijn, dwingt het wijzigen van het ene je niet om de anderen aan te raken. Wanneer ze verstrengeld zijn, kan zelfs een kleine wijziging door het hele systeem golven in manieren die niemand had voorspeld.

Waarom is dit belangrijk als je geen ontwikkelaar bent?

Omdat het rechtstreeks van invloed is op hoe snel en hoe veilig je software kan veranderen — en je bedrijf verandert constant: nieuwe prijsregels, een nieuw verkoopkanaal, een nieuwe wettelijke rapportagevereiste, een fusie die plots twee systemen met elkaar moet verbinden.

Dit is de concrete versie van het probleem, niet de abstracte:

Een distributiekantoor bouwde zijn kortingslogica rechtstreeks in de knop die een factuur afdrukt. Het werkte jarenlang prima. Toen vroeg sales om een nieuwe korting voor een klantencategorie. De ontwikkelaar moest door de layout van de factuur zoeken, de kortingsberekening vinden die in een knopactie was verborgen, diezelfde logica op twee andere plaatsen kopiëren waar kortingen ook iets anders werden berekend, en hopen dat alle drie voortaan synchroon bleven. Er werd er één gemist. Drie maanden later werd een klant gefactureerd met de verkeerde korting, en niemand kon uitleggen waarom — omdat dezelfde regel op drie plaatsen met drie iets verschillende versies bestond.

Als de kortingslogica op één plaats had geleefd — een enkele berekening die overal waar nodig werd gebruikt — zou die fix tien minuten in plaats van een week graven hebben gekost, en het kon niet uit synchroon zijn geraakt.

Hoe ziet het eruit wanneer separation of concerns ontbreekt?

Je hoeft geen code te lezen om waarschuwingssignalen op te spotten. Zoek naar:

• Dezelfde bedrijfsregel bestaat op meer dan één plaats. Een verzendkostenformule die in het bestellingenscherm wordt berekend, opnieuw in de factuur, en opnieuw in een rapport — zonder gedeelde bron.
• Een UI-wijziging breekt iets onverhouds. Je verplaatst een veld op een layout en een script dat naar de positie verwees, werkt niet meer.
• Niemand wil "dat oude script" aanraken. Het is zo verward geraakt met onverwante verantwoordelijkheden dat zelfs ervaren ontwikkelaars bang zijn het te wijzigen.
• Elke nieuwe functie duurt langer dan de vorige, ook al is je team niet minder bekwaam geworden — het systeem is gewoon meer verward geworden.
• Integraties zijn hardcoded in schermen. De aanroep naar je boekhoud-API zit in een knop op een bestelformulier, in plaats van achter een toegewijd, herbruikbaar connector.

Als twee of meer hiervan bekend voorkomen, kost separation of concerns je waarschijnlijk al tijd en geld — ook al heeft niemand het zo genoemd.

Hoe pas je separation of concerns toe in een echt systeem?

Je hoeft niet alles in één nacht opnieuw op te bouwen. In de praktijk passen teams het stapsgewijs toe:

1. Identificeer de herhaalde regel. Zoek bedrijfslogica die wordt gedupliceerd over schermen, rapporten of scripts (een korting, een belastingberekening, een goedkeuringregel).
2. Geef het één thuis. Verplaats die logica naar één script, functie of module die alles anders aanroept — in plaats van elke plaats onafhankelijk te laten berekenen.
3. Houd de interface dun. Een knop, een layout of een rapport moet de logica aanroepen en het resultaat weergeven — het mag de logica zelf niet bevatten.
4. Isoleer integraties achter een duidelijke grens. Met een externe API praten (boekhouden, e-commerce, een vervoerder) moet via één connector-laag gebeuren, niet verspreid over API-aanroepen in individuele schermen. Op die manier, als de externe API het format wijzigt, fix je het op één plaats.
5. Documenteer de grens, niet alleen de code. Zelfs een korte opmerking — "alle kortingslogica leeft in de Pricing-module" — helpt de volgende ontwikkelaar (of de volgende nieuweling) te weten waar je moet kijken en waar je geen shortcut moet toevoegen.

Geldt dit alleen voor aangepaste software?

Nee — het geldt net zozeer voor platforms zoals FileMaker, waar het verleidelijk is om snel te bouwen door logica rechtstreeks op knoppen en layouts te plaatsen, omdat het platform dat zo makkelijk maakt. Die snelheid is precies waarom FileMaker-systemen door de jaren heen in verward logica kunnen afdrijven: het is snel om een snelle berekening aan een knop toe te voegen, en snel tien keer over, totdat de knop vijf onverwante dingen doet.

Moderne tooling heeft goede scheiding eigenlijk makkelijker gemaakt, niet moeilijker. Tools zoals Klai, die AI-mogelijkheden in FileMaker brengen, werken het beste wanneer je bedrijfslogica al geïsoleerd en goed gedefinieerd is — een AI-assistent kan betrouwbaar de vraag "wat is ons retourbeleid?" beantwoorden alleen als dat beleid op één duidelijke plaats leeft in plaats van verborgen in een dozijn scripts. Evenzo zijn presentatie-frameworks zoals FmBetterForms gebouwd rond het idee van het scheiden hoe iets eruit ziet van hoe het werkt, dus een ontwerper kan de lay-out aanpassen zonder dat een ontwikkelaar bedrijfsregels hoeft aan te raken, en omgekeerd.

Wat is de opbrengst van dit goed doen?

• Snellere wijzigingen. Een prijsupdate raakt één module, niet vijf schermen.
• Veiligere wijzigingen. Het repareren van een bug in de presentatielaag kan niet per ongeluk de onderliggende bedrijfsregel breken.
• Gemakkelijkere onboarding. Nieuwe ontwikkelaars kunnen één laag tegelijk leren in plaats van alles tegelijk los te wikkelen.
• Betere integraties. Het verbinden van een nieuw systeem (een webshop, een vervoerder, een boekhoudpakket) is een kwestie van het aanroepen van je bestaande logica-laag, niet het herschrijven van regels een tweede keer.
• AI-gereedheid. Schone, goed gescheiden logica en data zijn precies wat AI-tools nodig hebben om processen betrouwbaar te automatiseren of vragen over.

Snelle checklist: scheidt je systeem concerns goed?

• Wordt enige bedrijfsregel (korting, belasting, goedkeuring, prijsstelling) op meer dan één plaats gedefinieerd?
• Kun je wijzigen hoe iets op het scherm eruit ziet zonder de logica erachter aan te raken?
• Zijn aanroepen naar externe systemen geïsoleerd in één connector-laag, of verspreid over schermen?
• Zou een nieuwe ontwikkelaar "waar de korting wordt berekend" in onder vijf minuten kunnen vinden?
• Heeft het toevoegen van een vergelijkbare nieuwe functie merkbaar langer geduurd dan de vorige?

Veelgestelde vragen

Is separation of concerns hetzelfde als "modulaire" software? Ze zijn nauw verwant. Modulariteit is vaak het resultaat van het toepassen van separation of concerns — zodra logica, data en presentatie schoon zijn gescheiden, breekt het systeem op natuurlijke wijze uiteen in modules die kunnen worden hergebruikt en uitgewisseld.

Kan een bestaand, verward systeem worden gerepareerd, of moet ik helemaal opnieuw beginnen? Bijna altijd kan het incrementeel worden gerepareerd. Je isoleert één regel tegelijk — beginnend met welke gedupliceerde logica ook de meeste ondersteuningstickets of fouten veroorzaakt — in plaats van het hele systeem tegelijk herschrijven.

Vertraagt dit de initiële ontwikkeling? Licht, in het begin — het kost wat meer discipline om het "enige thuis" voor een regel op te bouwen in plaats van simpelweg de logica te plakken waar je deze nodig hebt. Die kleine initiële kostprijs wordt consistent terugbetaald de eerste keer dat de regel moet veranderen.

Hoe is dit gerelateerd aan het onderhoudbaar houden van software op lange termijn? Separation of concerns is een van de fundamentele technieken achter onderhoudbare systemen — onze bredere gids over hoe je bedrijfssoftware onderhoudbaar houdt naarmate deze groeit behandelt dit naast andere praktijken zoals documentatie, code reviews en geplande refactoring.

Als je team meer tijd besteedt aan het ontwarren van oude logica dan aan het bouwen van nieuwe functies, is dat meestal een teken dat de concerns van je systeem in de loop der jaren verstrengeld zijn geraakt — en het is zelden iets wat je opmerkt tot het al duur is. Loggix helpt teams in kaart brengen waar bedrijfslogica, data en presentatie in hun FileMaker of aangepaste systemen verstrengeld zijn geraakt, en bouwt de connectors, modules of AI-tooling — inclusief oplossingen zoals Klai of FmBetterForms — nodig om ze veilig uit elkaar te trekken, zonder een verstorende volledige heropbouw.