Delphi modernizovať bez straty podnikovej logiky

Delphi-aplikácie bežia v mnohých spoločnostiach už roky stabilne – a zobrazujú presne tú doménovú logiku, ktorá zabezpečuje obrat, kvalitu služieb a súlad s predpismi. Pri modernizácii ide teda zriedka o „nové používateľské rozhranie“, skôr o kontrolovaný ďalší rozvoj, pri ktorom sa zachovávajú pravidlá, špecifické prípady a historické procesné znalosti.

V tomto príspevku ukazujeme praxou overený postup na postupnú modernizáciu Delphi: od inventarizácie cez oddelenie UI/prístupu k dátam až po technickú modernizáciu (Unicode/64‑Bit, BDE-nahradenie, API/služby) – vrátane zabezpečenia testami, monitorovaním a paralelným prevádzkovaním. Cieľom je architektúra umožňujúca modernizáciu, bez Big-Bang-Rewrite a bez straty logiky.

Modernizácie v praxi zriedka zlyhávajú kvôli kompilátoru alebo frameworku, ale kvôli nesprávnym predpokladom o správaní systému. Po roky vznikajúce Delphi-aplikácie typicky obsahujú doménové pravidlá v GUI-udalosťiach, SQL v logike formulárov, varianty pre zákazníka/mandanta, historicky podmienené výnimky a integrácie, ktoré sú zdokumentované len „v prevádzke“.

Big-Bang-Rewrite prinúti tieto znalosti rekonštruovať nanovo – vrátane chýb, ktoré starý systém už dávno nerobí. Lepší prístup je považovať doménovú logiku za aktívum: izolovať ju, zabezpečiť a potom krok za krokom modernizovať.

Udržateľná cieľová vízia pre procesne kritické B2B systémy nie je „všetko nové“, ale architektúra, ktorá umožňuje zmeny – bez ohrozenia bežiacej prevádzky:

• jasné oddelenie UI, doménovej logiky, prístupu k dátam a integrácií
• testovateľnosť a merateľnosť (regresné testovanie, logging, monitoring, reprodukovateľné zostavenia)
• postupná zameniteľnosť (modernizovať UI bez okamžitej migrácie DB – alebo naopak)
• schopnosť API (napr. REST), na prepojenie portálov, mobilných riešení alebo systémových integrácií
• nasadenia schopné prevádzky s možnosťou rollbacku

Delphi sa na to hodí dobre, pretože existujúce jednotky a doménové triedy možno ďalej používať, zatiaľ čo okolité vrstvy sa modernizujú.

Skôr než sa upraví kód, treba spoľahlivý podklad pre rozhodnutie – nie kompletnú dokumentáciu. Osvedčili sa tieto tri výstupy:

• Mapa doménovej logiky: kritické prípady použitia, pravidlá/vypočty, varianty (mandanti/krajiny/zákazníci), rozhrania, pracovné úlohy/batch-behy.
• Rizikový profil: obzvlášť na chyby citlivé oblasti, kvalita dát, regulačné požiadavky, prevádzkové úzke miesta (výkon, stabilita, udržiavateľnosť).
• Backlog modernizácie: prioritné balíky podľa obchodnej hodnoty a rizika (čo musí zostať stabilné, čo sa môže zmeniť, čo neskôr).

To umožní spravovať modernizáciu plánovateľne: s jasnými inkrementmi namiesto jediného „všetko-alebo-nič“ projektu.

Aby sa doménová logika nemenila „neúmyselne“, treba zabezpečenie, ktoré funguje nezávisle od UI-refaktoringu. Typické stavebné prvky:

• Characterization/Golden-Master-Tests: existujúce správanie sa pomocou reprezentatívnych vstupov/výstupov zamrazí (reporty, výpočty, procesné kroky).
• Regresné testy na úrovni prípadov použitia: obchodne kritické toky sa simulujú automatizovane alebo polautomatizovane.
• Telemetry: logging, metriky a chybové stavy sa pred a po zmene porovnateľne zaznamenajú.
• Parallelbetrieb & kontrollierte Umstellung: nové moduly bežia popri existujúcom systéme (Feature Toggles, pilotné skupiny) s jasnou rollback-stratégiou.

Až keď sú tieto bezpečnostné siete zavedené, má zmysel vlastná technická modernizácia – pretože riziko a potreba dodatočných úprav výrazne klesajú.

Najčastejším dôvodom straty logiky je miešanie UI, prístupu k dátam a doménových pravidiel. Modernizácia preto začína oddelením — nie výmenou UI-frameworku.

Pragmatickým cieľom je 3‑vrstvová štruktúra:

• Presentation: VCL/FMX, Presenter/ViewModel, len UI-príbuzná validácia (formát, povinné polia)
• Business: doménové modely, služby, pravidlá, logika stavov, výpočty
• Data/Integration: repozitáre, prístup k DB, adaptéry na ERP/DMS/CRM, REST-Clients, messaging

Pravidlo z praxe: Doménové pravidlá by sa mali presunúť z OnClick/OnExit do doménových služieb. SQL by sa malo presunúť z Forms do repozitárov. Tým sa logika stane testovateľnou a neskôr opätovne použiteľnou cez UI, služby a úlohy.

Pri Strangulation Pattern vzniká nové cielene „vedľa“ existujúceho systému: nové funkcie sa implementujú už v odpojenej štruktúre, zatiaľ čo starý systém beží ďalej. Krok za krokom preberá nová vrstva viac zodpovednosti, až staré časti odpadnú.

Príklad (typické B2B):

• Extrahujete objednávkovú logiku do doménového servisu.
• Existujúce VCL-UI najprv používa ten istý servis (bez prerušenia procesu).
• Paralelne vzniká REST-koncový bod pre zákaznícke portál alebo integráciu.
• Po stabilizácii sú jednotlivé staré Forms nahradené – bez toho, aby bolo potrebné prestavať jadrovú logiku.

Tým znižujete riziko projektu, zachovávate prevádzkyschopnosť a rýchlo získavate merateľný úžitok (napr. API, výkon, udržiavateľnosť).

V závislosti od východiskovej situácie sú tieto stavebné kamene často relevantné – rozhodujúca je priorizácia podľa rizika a obchodnej hodnoty:

• BDE/Legacy-DB-Zugriff ablösen: moderné ovládače/provideri, jasné hranice transakcií, reprodukovateľné nasadenia.
• Unicode: spracovanie reťazcov, databáza/rozhrania, komponenty tretích strán.
• 64‑Bit: závislosti, pamäť/výkon, externé knižnice.
• API- a servisná vrstva: REST, Windows-/Linux-Services, integrácie.
• Build & Release: CI/CD, manažment artefaktov, podpísané inštalátory, rollback.

Dôležité: Tieto body by sa ideálne mali realizovať po oddelení a zabezpečení – potom je možné zmeny bezpečne overiť.

Kompletný prepis je v niektorých prípadoch zmysluplný – často je to však najdrahšia cesta k získaniu „modernej techniky“. Tieto otázky pomáhajú pri rozhodovaní:

• Je doménová logika úplne pochopená a testovateľná – alebo je veľa znalostí implicitne uložených v prevádzke?
• Existujú tvrdé termíny (napr. koniec platformy, compliance), ktoré vylučujú paralelný režim prevádzky?
• Aká veľká je rôznorodosť variant (logika zákazníkov/mandantov)?
• Ako kritická je dostupnosť a aká vysoká je tolerancia voči zmenám procesov?
• Ktoré časti sú naozaj „vinou“ (UI, prístup k dátam, integrácie, deployment) – a ktoré sú stabilné?

V mnohých B2B scenároch vedie postupný prístup rýchlejšie k merateľným výsledkom, pretože kontroluje riziká a chráni doménovú logiku.

Delphi-Audit modernizácie (pre procesne kritické aplikácie): Analyzujeme architektúru, závislosti, oblasti rizika a dodáme priorizovanú roadmapu, ako modernizovať bez straty doménovej logiky.

• Vstup: Codebasis (len na čítanie), Build-Setup, 2–3 kľúčové prípady použitia, systémové prostredie (DB, integrácie).
• Výsledok: Mapa funkčnej logiky a modulov, analýza rizík a závislostí, odporúčaná cieľová architektúra, plán implementácie v inkrementoch vrátane zabezpečenia (testy / paralelný prevádzkový režim).
• Voliteľné: Proof of Concept pre oddelenie + prvý Golden-Master-Test.

Tak získate spoľahlivý podklad pre rozhodovanie, skôr než sa rozpočet a čas investujú do rizikantného prepisu.

Môže sa Delphi modernizovať bez opätovného prepísania aplikácie?
Áno. V mnohých prípadoch sa najprv oddelí funkčná logika a prístup k dátam, potom sa technicky modernizuje. To znižuje riziko a udržuje prevádzku stabilnú.

Ako zabrániť tomu, aby sa funkčná logika „potichu“ menila?
Prostredníctvom Golden-Master-/regresných testov, telemetrie a kontrolovaného paralelného prevádzkového režimu s jasnou rollback-stratégiou.

Ktoré kroky často prinesú najskorší prínos?
Transparentnosť (Assessment), oddelenie UI/SQL, BDE-nahradenie a vrstva API/služieb pre integrácie – vždy zabezpečené testami.

Ako dlho trvá modernizácia?
To závisí od kritických Use-Cases, rôznorodosti variantov a závislostí. Audit obvykle v krátkom čase poskytne spoľahlivú roadmapu a prioritizované inkrementy.