Modernitzar Delphi sense perdre la lògica de negoci

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, reemplaçament de BDE, 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:

• Tests de caracterització/Golden-Master: vorhandenes Verhalten wird über repräsentative Eingaben/Ausgaben eingefroren (Reports, Berechnungen, Prozessschritte).
• Proves de regressió a nivell de casos d’ús: die geschäftskritischen Abläufe werden automatisiert oder halbautomatisiert nachgestellt.
• Telemetria: 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.

Només quan aquestes xarxes de seguretat estiguin en funcionament, val la pena la modernització tècnica pròpiament dita – perquè el risc i el retraball disminueixen dràsticament.

La causa més freqüent de pèrdua de lògica és la barreja d’UI, accés a dades i regles de negoci. Per això la modernització comença amb el desacoblament – no amb el canvi del framework d’UI.

Un objectiu pragmàtic és una estructura de 3 capes:

• Presentation: VCL/FMX, Presenter/ViewModel, només validació pròxima a la UI (format, camps obligatoris)
• Business: models de domini, serveis, regles, lògica d’estat, càlculs
• Data/Integration: Repositories, accés a BD, adaptadors a ERP/DMS/CRM, REST-Clients, Messaging

Regla pràctica: les regles de negoci passen d’OnClick/OnExit a serveis de domini. El SQL es trasllada dels Forms a Repositories. Així la lògica esdevé testable i, més endavant, reutilitzable des de la UI, serveis i jobs.

Amb l’Strangulation Pattern sorgeix el nou de manera deliberada „al costat“ de l’existent: les noves funcions s’implementen ja en l’estructura desacoblada, mentre el sistema antic continua funcionant. Pas a pas la nova capa assumeix més responsabilitat, fins que les parts antigues deixen d’existir.

Exemple (típic B2B):

• S’extreu la lògica d’ordres a un servei de domini.
• La VCL-UI existent utilitza inicialment el mateix servei (sense trencament de procés).
• En paral·lel sorgeix un REST-endpoint per a un portal de clients o per a una integració.
• Després de l’estabilització es substitueixen formularis antics individuals – sense que calgui reconstruir la lògica central.

Així reduïu el risc del projecte, conserveu la capacitat operativa i obteniu ràpidament benefici mesurable (p. ex. API, rendiment, mantenibilitat).

Segons la situació inicial, aquests blocs sovint són rellevants – el decisiu és la priorització segons risc i valor de negoci:

• BDE/Legacy-DB-Zugriff ablösen: controladors/proveïdors moderns, límits de transacció nets, desplegaments reproducibles.
• Unicode: gestió de cadenes de caràcters, base de dades/interfícies, components de tercers.
• 64‑Bit: dependències, memòria/rendiment, llibreries externes.
• API- und Service-Schicht: REST, Windows-/Linux-Services, integracions.
• Build & Release: CI/CD, gestió d’artefactes, instal·ladors signats, rollback.

Important: aquests punts s’han d’implementar idealment després del desacoblament i de l’assegurament – així els canvis es poden verificar amb seguretat.

Un rewrite complet té sentit en alguns casos – però sovint és la via més cara per obtenir „tecnologia moderna“. Aquestes preguntes ajuden a la valoració:

• La lògica de negoci està completament entesa i sotmesa a proves – o hi ha molt de coneixement implícit en l’explotació?
• Hi ha terminis estrictes (p. ex. final de plataforma, compliance) que exclouen un funcionament en paral·lel?
• Quina és l’amplitud de variants (lògica per clients/mandants)?
• Quina criticitat té la disponibilitat i quina tolerància hi ha per als canvis de procés?
• Quines parts són realment „culpables“ (UI, accés a dades, integracions, deployment) – i quines són estables?

En molts escenaris B2B un enfocament gradual porta més ràpidament a resultats mesurables, perquè controla riscos i protegeix la lògica de negoci.

Delphi-Modernisierungs-Audit (per a aplicacions crítiques de procés): analitzem l’arquitectura, les dependències, les àrees de risc i subministrem una fulla de ruta prioritzada sobre com modernitzar sense perdre la lògica de negoci.

• Entrada: base de codi (read-only), Build-Setup, 2–3 casos d’ús clau, entorn del sistema (BD, integracions).
• Resultat: Mapa de la lògica de negoci/moduls, anàlisi de riscos i dependències, arquitectura objectiu recomanada, pla d’implementació per increments incl. assegurament (tests/operació en paral·lel).
• Opcional: Proof of Concept per al desacoblament + primer test de Golden-Master.

Així obté una base de decisió sòlida abans que pressupost i temps es destinin a una reescriptura arriscada.

Es pot modernitzar Delphi sense reescriure l’aplicació?
Sí. En molts casos, primer es desacoblen la lògica de negoci i l’accés a dades, i a continuació es modernitza tècnicament. Això redueix el risc i manté estable l’explotació.

Com s’evita que la lògica de negoci es modifiqui de manera „silenciosa“?
Mitjançant tests de Golden-Master i de regressió, telemetria i un funcionament en paral·lel controlat amb una estratègia de rollback clara.

Quins passos aporten sovint el benefici més ràpid?
Transparència (Assessment), desacoblament de UI/SQL, BDE-substitució i una capa d’API/servei per a integracions – tots ells assegurats mitjançant tests.

Quant de temps triga una modernització?
Depèn dels casos d’ús crítics, la diversitat de variants i les dependències. Una auditoria sol proporcionar, en poc temps, una fulla de ruta sòlida i increments prioritzats.