Modernizzare Delphi senza perdere la logica di dominio

Delphi-Anwendungen laufen in vielen Unternehmen seit Jahren stabil – und bilden genau die Fachlogik ab, die Umsatz, Servicequalität und Compliance sichert. Bei einer Modernisierung geht es daher selten um „neue Oberfläche“, sondern um eine kontrollierte Weiterentwicklung, bei der Regeln, Sonderfälle und historisches Prozesswissen erhalten bleiben.

In diesem Beitrag zeigen wir ein praxiserprobtes Vorgehen, um Delphi schrittweise zu modernisieren: von der Bestandsaufnahme über die Entkopplung von UI/Datenzugriff bis zur technischen Modernisierung (Unicode/64‑Bit, BDE-Ablösung, API/Services) – inklusive Absicherung durch Tests, Monitoring und Parallelbetrieb. Ziel ist eine modernisierbare Architektur, ohne Big-Bang-Rewrite und ohne Logikverlust.

Modernisierungen scheitern in der Praxis selten am Compiler oder an einem Framework, sondern an falschen Annahmen über das Systemverhalten. Über Jahre gewachsene Delphi-Anwendungen enthalten typischerweise Fachregeln in GUI-Events, SQL in Formularlogik, Varianten pro Kunde/Mandant, historisch bedingte Sonderfälle sowie Integrationen, die nur „im Betrieb“ dokumentiert sind.

Ein Big-Bang-Rewrite zwingt dazu, dieses Wissen neu zu rekonstruieren – inklusive der Fehler, die das Altsystem längst nicht mehr macht. Der bessere Ansatz ist, die Fachlogik als Vermögenswert zu behandeln: isolieren, absichern, dann Schritt für Schritt modernisieren.

Ein tragfähiges Zielbild für prozesskritische B2B-Systeme ist nicht „alles neu“, sondern eine Architektur, die Veränderungen ermöglicht – ohne den laufenden Betrieb zu gefährden:

• klare Trennung von UI, Domänenlogik, Datenzugriff und Integrationen
• Test- und Messbarkeit (Regression, Logging, Monitoring, reproduzierbare Builds)
• schrittweise Austauschbarkeit (UI modernisieren ohne sofortige DB-Migration – oder umgekehrt)
• API-Fähigkeit (z. B. REST), um Portale, Mobile oder System-Integrationen anzubinden
• betriebsfähige Deployments mit Rollback-Option

Delphi eignet sich dafür gut, weil bestehende Units und Domänenklassen weiterverwendet werden können, während außen herum modernisiert wird.

Bevor Code angepasst wird, braucht es eine belastbare Entscheidungsgrundlage – keine Voll-Dokumentation. Bewährt haben sich diese drei Ergebnisse:

• Fachlogik-Landkarte: kritische Use-Cases, Regeln/Berechnungen, Varianten (Mandanten/Länder/Kunden), Schnittstellen, Jobs/Batch-Läufe.
• Risikoprofil: besonders fehlerkritische Bereiche, Datenqualität, regulatorische Anforderungen, Engpässe im Betrieb (Performance, Stabilität, Wartbarkeit).
• Modernisierungs-Backlog: priorisierte Pakete nach Business-Wert und Risiko (was muss stabil bleiben, was darf sich ändern, was später).

Damit lässt sich Modernisierung planbar machen: mit klaren Inkrementen statt einem einzigen „Alles-oder-nichts“-Projekt.

Damit Fachlogik nicht „versehentlich“ verändert wird, braucht es eine Absicherung, die unabhängig vom UI-Refactoring funktioniert. Typische Bausteine:

• Characterization/Golden-Master-Tests: vorhandenes Verhalten wird über repräsentative Eingaben/Ausgaben eingefroren (Reports, Berechnungen, Prozessschritte).
• Regressionstests auf Use-Case-Ebene: die geschäftskritischen Abläufe werden automatisiert oder halbautomatisiert nachgestellt.
• Telemetry: Logging, Metriken und Fehlerbilder werden vor/nach einer Änderung vergleichbar gemacht.
• Parallelbetrieb & kontrollierte Umstellung: neue Module laufen neben dem Bestand (Feature Toggles, Pilotgruppen), mit klarer Rollback-Strategie.

Solo quando queste reti di sicurezza sono al loro posto, vale la pena procedere con la vera modernizzazione tecnica – perché rischio e lavoro di rielaborazione diminuiscono drasticamente.

La causa più comune della perdita di logica è la mescolanza di UI, accesso ai dati e regole di dominio. La modernizzazione inizia quindi dal disaccoppiamento – non dalla sostituzione del framework UI.

Un obiettivo pragmatico è una struttura a 3 livelli:

• Presentation: VCL/FMX, Presenter/ViewModel, solo validazioni vicine alla UI (formato, campi obbligatori)
• Business: modelli di dominio, servizi, regole, logica di stato, calcoli
• Data/Integration: repository, accesso al DB, adapter per ERP/DMS/CRM, REST-Clients, messaggistica

Regola pratica: le regole di dominio si spostano da OnClick/OnExit nei servizi di dominio. SQL si sposta dai Forms nei repository. In questo modo la logica diventa testabile e più tardi riutilizzabile tramite UI, servizi e job.

Con lo Strangulation Pattern il nuovo viene creato intenzionalmente „accanto“ al sistema esistente: le nuove funzionalità vengono implementate già nella struttura disaccoppiata, mentre il sistema legacy continua a funzionare. Passo dopo passo il nuovo strato assume sempre più responsabilità, fino a che le parti vecchie vengono eliminate.

Esempio (tipico B2B):

• Si estrae la logica degli ordini in un servizio di dominio.
• La VCL-UI esistente usa inizialmente lo stesso servizio (nessuna interruzione di processo).
• Parallelamente viene creato un endpoint REST per un portale clienti o per un’integrazione.
• Dopo la stabilizzazione, singoli Forms vecchi vengono sostituiti – senza che sia necessario ricostruire la logica centrale.

Così si riduce il rischio di progetto, si mantiene l’operatività e si ottiene rapidamente un beneficio misurabile (p.es. API, prestazioni, manutenibilità).

A seconda della situazione di partenza questi elementi sono spesso rilevanti – decisiva è la priorizzazione in base al rischio e al valore di business:

• BDE/Sostituire l’accesso DB legacy: driver/provider moderni, confini transazionali puliti, deployment riproducibili.
• Unicode: gestione delle stringhe, database/interfacce, componenti di terze parti.
• 64‑Bit: dipendenze, memoria/prestazioni, librerie esterne.
• API e strato di servizio: REST, Windows-/Linux-Services, integrazioni.
• Build & Release: CI/CD, gestione degli artefatti, installer firmati, rollback.

Importante: questi punti dovrebbero idealmente essere implementati dopo il disaccoppiamento e la messa in sicurezza – in tal modo le modifiche possono essere verificate in modo sicuro.

Un rewrite completo è in alcuni casi sensato – spesso però è la via più costosa per ottenere „tecnologia moderna“. Queste domande aiutano a valutare:

• La logica di dominio è completamente compresa e testabile – o c’è molta conoscenza implicita operativa?
• Esistono scadenze stringenti (p.es. fine piattaforma, compliance) che escludono un funzionamento in parallelo?
• Quanto è ampia la varietà di varianti (logica clienti/mandanti)?
• Quanto è critica la disponibilità e quale tolleranza esiste per le modifiche di processo?
• Quali parti sono realmente „colpevoli“ (UI, accesso ai dati, integrazioni, deployment) – e quali sono stabili?

In molti scenari B2B un approccio graduale porta più rapidamente a risultati misurabili, perché controlla i rischi e protegge la logica di dominio.

Delphi-Modernisierungs-Audit (per applicazioni critiche di processo): Analizziamo architettura, dipendenze, aree a rischio e forniamo una roadmap prioritaria su come modernizzare senza perdere la logica di dominio.

• Input: codebase (read-only), setup di build, 2–3 use-case chiave, contesto di sistema (DB, integrazioni).
• Risultato: mappa della logica di dominio/dei moduli, analisi dei rischi e delle dipendenze, architettura target raccomandata, piano di attuazione per incrementi incl. messa in sicurezza (test/operatività in parallelo).
• Opzionale: Proof of Concept per il disaccoppiamento + primo test Golden-Master.

In questo modo ottiene una base decisionale solida prima che budget e tempo vengano investiti in una riscrittura rischiosa.

Si può modernizzare Delphi senza riscrivere l’applicazione?
Sì. In molti casi si disaccoppiano prima la logica di dominio e l’accesso ai dati, quindi si procede alla modernizzazione tecnica. Questo riduce i rischi e mantiene stabile l’operatività.

Come si impedisce che la logica di dominio venga modificata „silenziosamente“?
Attraverso test Golden-Master/di regressione, telemetria e un’operatività parallela controllata con una strategia di rollback chiara.

Quali interventi portano spesso il beneficio più rapido?
Trasparenza (Assessment), disaccoppiamento di UI/SQL, sostituzione di BDE e uno strato API/di servizio per le integrazioni – ciascuno garantito da test.

Quanto tempo richiede una modernizzazione?
Dipende dai casi d’uso critici, dalla molteplicità delle varianti e dalle dipendenze. Un audit fornisce tipicamente in breve tempo una roadmap affidabile e incrementi prioritizzati.