Delphi moderniseren zonder domeinlogica te verliezen

Delphi-applicaties draaien in veel bedrijven al jaren stabiel – en weerspiegelen precies de domeinlogica die omzet, servicekwaliteit en compliance waarborgt. Bij modernisering gaat het daarom zelden om een „nieuwe gebruikersinterface“, maar om een gecontroleerde doorontwikkeling waarbij regels, uitzonderingsgevallen en historisch proceskennis behouden blijven.

In dit artikel tonen we een in de praktijk beproefde aanpak om Delphi stapsgewijs te moderniseren: van de inventarisatie via het ontkoppelen van UI/data-toegang tot de technische modernisering (Unicode/64‑Bit, BDE-vervanging, API/services) – inclusief waarborging door tests, monitoring en parallelle werking. Doel is een moderniseerbare architectuur, zonder Big-Bang-rewrite en zonder verlies van logica.

Moderniseringen mislukken in de praktijk zelden door de compiler of door een framework, maar door verkeerde aannames over het systeemgedrag. Over jaren gegroeide Delphi-applicaties bevatten typisch domeinregels in GUI-events, SQL in formulierlogica, varianten per klant/mandant, historisch bepaalde uitzonderingsgevallen en integraties die alleen „in de operatie“ gedocumenteerd zijn.

Een Big-Bang-rewrite dwingt ertoe deze kennis opnieuw te reconstrueren – inclusief de fouten die het legacy-systeem allang niet meer maakt. De betere aanpak is om de domeinlogica als een activum te behandelen: isoleren, waarborgen, en vervolgens stap voor stap moderniseren.

Een houdbaar doelbeeld voor proceskritische B2B-systemen is niet „alles nieuw“, maar een architectuur die veranderingen mogelijk maakt – zonder de continuïteit van de operatie in gevaar te brengen:

• duidelijke scheiding van UI, domeinlogica, data-toegang en integraties
• test- en meetbaarheid (regressie, logging, monitoring, reproduceerbare builds)
• stapsgewijze vervangbaarheid (UI moderniseren zonder directe DB-migratie – of omgekeerd)
• API-mogelijkheid (bijv. REST), om portalen, mobiele toepassingen of systeemintegraties aan te sluiten
• bedrijfsklare deployments met rollback-optie

Delphi leent zich daar goed voor, omdat bestaande units en domeinklassen hergebruikt kunnen worden terwijl de buitenkant wordt gemoderniseerd.

Voordat code wordt aangepast is een betrouwbare beslissingsbasis nodig – geen volledige documentatie. De volgende drie resultaten hebben zich bewezen:

• Kaart van domeinlogica: kritieke use-cases, regels/berekeningen, varianten (mandanten/landen/klanten), interfaces, jobs/batchruns.
• Risicoprofiel: bijzonder foutkritische gebieden, datakwaliteit, reglementaire eisen, knelpunten in de operatie (performance, stabiliteit, onderhoudbaarheid).
• Moderniseringsbacklog: geprioriteerde pakketten naar businesswaarde en risico (wat moet stabiel blijven, wat mag veranderen, wat later).

Zo wordt modernisering planbaar: met duidelijke incrementele stappen in plaats van één „alles-of-niets“-project.

Om te voorkomen dat domeinlogica „per ongeluk“ verandert, is een waarborging nodig die onafhankelijk van het UI-refactoring werkt. Typische bouwstenen:

• Characterization/Golden-Master-tests: bestaand gedrag wordt met representatieve input/output bevroren (reports, berekeningen, processtappen).
• Regressietests op use-case-niveau: de bedrijfskritische workflows worden geautomatiseerd of half-geautomatiseerd nagebootst.
• Telemetrie: logging, metrics en foutbeelden worden voor/na een wijziging vergelijkbaar gemaakt.
• Parallelle operatie & gecontroleerde omschakeling: nieuwe modules draaien naast het bestaande (feature toggles, pilotgroepen), met een duidelijke rollback-strategie.

Pas wanneer deze vangnetten aanwezig zijn, is de daadwerkelijke technische modernisering de moeite waard – omdat risico’s en nabehandeling drastisch afnemen.

De meest voorkomende oorzaak van verlies van logica is het vermengen van UI, gegevens‑toegang en domeinregels. Modernisering begint daarom met ontkoppeling – niet met het vervangen van het UI-framework.

Een pragmatisch doel is een 3‑lagenstructuur:

• Presentation: VCL/FMX, Presenter/ViewModel, alleen UI‑nabije validatie (formaat, verplichte velden)
• Business: domeinmodellen, services, regels, toestandslogica, berekeningen
• Data/Integration: repositories, DB-toegang, adapters naar ERP/DMS/CRM, REST-clients, messaging

Praktijkregel: domeinregels verhuizen uit OnClick/OnExit naar domeinservices. SQL verplaatst zich uit Forms naar repositories. Zo wordt logica testbaar en later herbruikbaar via UI, services en jobs.

Bij het Strangulation Pattern ontstaat het nieuwe doelbewust „naast“ het bestaande: nieuwe functies worden al in de ontkoppelde structuur geïmplementeerd, terwijl het legacy-systeem blijft draaien. Stap voor stap neemt de nieuwe laag meer verantwoordelijkheid over, tot oude delen vervallen.

Voorbeeld (typisch B2B):

• U extraheert de orderlogica in een domeinservice.
• De bestaande VCL-UI gebruikt aanvankelijk dezelfde service (geen procesbreuk).
• Parallel ontstaat een REST-endpoint voor een klantenportaal of een integratie.
• Na stabilisatie worden individuele oude Forms vervangen – zonder dat de kernlogica opnieuw opgebouwd hoeft te worden.

Zo verlaagt u het projectrisico, behoudt u de operationele continuïteit en realiseert u snel meetbare voordelen (bijv. API, performance, onderhoudbaarheid).

Afhankelijk van de uitgangssituatie zijn deze bouwstenen vaak relevant – bepalend is de prioritering op risico en businesswaarde:

• BDE/Legacy-DB-Zugriff ablösen: moderne drivers/providers, duidelijke transactiezones, reproduceerbare Deployments.
• Unicode: string‑handling, database/interfaces, componenten van derden.
• 64‑Bit: afhankelijkheden, geheugen/performance, externe libraries.
• API- und Service-Schicht: REST, Windows-/Linux-Services, integraties.
• Build & Release: CI/CD, artefactbeheer, gesigneerde installers, rollback.

Belangrijk: deze punten worden bij voorkeur na ontkoppeling en beveiliging uitgevoerd – dan kunnen wijzigingen veilig worden geverifieerd.

Een volledige rewrite is in sommige gevallen zinvol – vaak is het echter de duurste weg om „moderne technologie“ te verkrijgen. Deze vragen helpen bij de beoordeling:

• Is de domeinlogica volledig begrepen en testbaar – of zit veel kennis impliciet in de operatie?
• Zijn er harde deadlines (bijv. einde platform, compliance) die parallelle exploitatie uitsluiten?
• Hoe groot is de variantenrijkdom (klant-/tenantlogica)?
• Hoe kritisch is de beschikbaarheid, en hoe groot is de tolerantie voor proceswijzigingen?
• Welke onderdelen zijn werkelijk „schuldig“ (UI, gegevens‑toegang, integraties, deployment) – en welke zijn stabiel?

In veel B2B-scenario’s leidt een stapsgewijze aanpak sneller tot meetbare resultaten, omdat hij risico’s beheerst en de domeinlogica beschermt.

Delphi-Modernisierungs-Audit (voor proceskritische toepassingen): wij analyseren architectuur, afhankelijkheden, risicogebieden en leveren een geprioritiseerde roadmap hoe u moderniseert zonder domeinlogica te verliezen.

• Input: codebasis (read-only), Build-Setup, 2–3 Kern-Use-Cases, Systemumfeld (DB, Integrationen).
• Resultaat: domeinlogica-/module-landkaart, risico- en afhankelijkheidsanalyse, aanbevolen doelarchitectuur, implementatieplan in incrementele stappen incl. borging (tests/parallelle exploitatie).
• Optioneel: Proof of Concept voor ontkoppeling + eerste Golden-Master-test.

Zo krijgt u een solide beslissingsbasis voordat budget en tijd in een risicovolle herschrijving vloeien.

Is het mogelijk Delphi te moderniseren zonder de applicatie opnieuw te schrijven?
Ja. In veel gevallen worden eerst domeinlogica en gegevenstoegang ontkoppeld, daarna technisch gemoderniseerd. Dat verkleint het risico en houdt de exploitatie stabiel.

Hoe voorkomt u dat domeinlogica „stil“ wordt gewijzigd?
Door Golden-Master-/regressietests, telemetrie en een gecontroleerde parallelle exploitatie met een duidelijke rollback-strategie.

Welke stappen leveren vaak het snelste voordeel op?
Transparantie (Assessment), ontkoppeling van UI/SQL, BDE-vervanging en een API-/service-laag voor integraties – telkens afgedekt door tests.

Hoe lang duurt een modernisering?
Dat hangt af van kritische use-cases, variantendiversiteit en afhankelijkheden. Een audit levert doorgaans binnen korte tijd een betrouwbare roadmap en geprioriteerde incrementele stappen.