Delphi modernizovat bez ztráty doménové logiky

Delphi-aplikace běží v mnoha firmách roky stabilně – a přesně odrážejí doménovou logiku, která zajišťuje obrat, kvalitu služeb a soulad s předpisy. Při modernizaci tedy málokdy jde o „nové rozhraní“, ale o kontrolovaný další rozvoj, při kterém zůstávají zachována pravidla, výjimky a historické procesní znalosti.

V tomto článku ukazujeme osvědčený postup, jak postupně modernizovat Delphi: od inventarizace přes oddělení UI/přístupu k datům až po technickou modernizaci (Unicode/64‑Bit, BDE-náhrada, API/služby) – včetně zabezpečení pomocí testů, monitoringu a paralelního provozu. Cílem je architektura umožňující modernizaci, bez Big-Bang-rewrite a bez ztráty logiky.

V praxi modernizace zřídka selhávají kvůli překladači nebo frameworku, ale kvůli chybným předpokladům o chování systému. Po letech vzniklé Delphi-aplikace obvykle obsahují doménová pravidla v událostech GUI, SQL v logice formulářů, varianty pro zákazníka/mandanta, historicky podmíněné výjimky a integrace, které jsou zdokumentovány jen „v provozu“.

Big-Bang-rewrite nutí rekonstruovat tyto znalosti – včetně chyb, které starý systém už dávno nedělá. Lepší přístup je považovat doménovou logiku za aktivum: izolovat, zabezpečit, a poté krok za krokem modernizovat.

Udržitelná cílová vize pro procesně kritické B2B systémy není „vše nové“, ale architektura, která umožňuje změny – aniž by ohrozila běžný provoz:

• jasné oddělení UI, doménové logiky, přístupu k datům a integrací
• testovatelnost a měřitelnost (regrese, logování, monitoring, reprodukovatelné buildy)
• postupná zaměnitelnost (modernizace UI bez okamžité migrace DB – nebo naopak)
• podpora API (např. REST), pro připojení portálů, mobilních klientů nebo systémových integrací
• provozuschopná nasazení s možností rollbacku

Delphi je pro to vhodný, protože stávající jednotky a doménové třídy mohou být znovu využity, zatímco se modernizuje okolí.

Než se upraví kód, je potřeba spolehlivý podklad pro rozhodnutí – ne úplná dokumentace. Osvědčily se tyto tři výsledky:

• Mapa doménové logiky: kritické případy použití, pravidla/výpočty, varianty (mandanti/země/zákazníci), rozhraní, úlohy/batch běhy.
• Profil rizik: zvláště chybově kritické oblasti, kvalita dat, regulatorní požadavky, provozní úzká místa (výkon, stabilita, udržovatelnost).
• Modernizační backlog: prioritizované balíčky podle obchodní hodnoty a rizika (co musí zůstat stabilní, co se může změnit, co až později).

Tím lze modernizaci udělat plánovatelnou: jasnými přírůstky místo jediného „vše-nebo-nic“-projektu.

Aby se doménová logika „náhodou“ nezměnila, je potřeba zabezpečení, které funguje nezávisle na UI-refaktoringu. Typické stavební prvky:

• Characterization/Golden-Master-Tests: existující chování je pomocí reprezentativních vstupů/výstupů „zmrazeno“ (reporty, výpočty, kroky procesu).
• Regresní testy na úrovni případů použití: obchodně kritické procesy jsou automatizovaně nebo poloautomatizovaně reprodukovány.
• Telemetrie: logování, metriky a chybové stavy jsou před/po změně srovnatelné.
• Paralelní provoz & kontrolovaná přechodová fáze: nové moduly běží vedle stávajícího systému (Feature Toggles, pilotní skupiny), s jasnou rollbackovou strategií.

Teprve když jsou tato bezpečnostní síťe zavedena, má smysl samotná technická modernizace – protože riziko a následné dodatečné práce výrazně klesají.

Nejčastější příčinou ztráty logiky je promíchání UI, přístupu k datům a obchodních pravidel. Modernizace proto začíná oddělením – nikoli výměnou UI‑frameworku.

Pragmatickým cílem je struktura se 3 vrstvami:

• Presentation: VCL/FMX, Presenter/ViewModel, pouze validace blízká UI (formát, povinná pole)
• Business: doménové modely, služby, pravidla, logika stavů, výpočty
• Data/Integration: Repositories, přístup k DB, adaptéry na ERP/DMS/CRM, REST-Clients, Messaging

Pravidlo z praxe: odborná pravidla se přesouvají z OnClick/OnExit do doménových služeb. SQL se přesouvá z Forms do Repositories. Tak se logika stává testovatelnou a později znovu použitelnou přes UI, služby a úlohy.

Při Strangulation Pattern vzniká nové cíleně „vedle“ existujícího systému: nové funkce jsou implementovány již v odpojené struktuře, zatímco starý systém pokračuje v provozu. Krok za krokem přebírá nová vrstva více odpovědnosti, až staré části odpadnou.

Příklad (typické B2B):

• Extrahujete logiku objednávek do doménového servisu.
• Existující VCL‑UI nejprve používá tentýž servis (bez přerušení procesu).
• Paralelně vzniká REST-koncový bod pro zákaznické rozhraní nebo integraci.
• Po stabilizaci jsou jednotlivé staré Forms nahrazovány – aniž by bylo nutné jádrovou logiku znovu vybudovat.

Tím snížíte riziko projektu, zachováte provozuschopnost a rychle získáte měřitelný přínos (např. API, výkon, udržovatelnost).

V závislosti na výchozí situaci jsou tyto stavební kameny často relevantní – rozhodující je prioritizace podle rizika a obchodní hodnoty:

• BDE/nahradit Legacy‑DB přístup: moderní ovladače/provider, čisté transakční hranice, reprodukovatelné nasazení.
• Unicode: zpracování řetězců, databáze/rozhraní, komponenty třetích stran.
• 64‑Bit: závislosti, paměť/výkon, externí knihovny.
• API- und Service-Schicht: REST, Windows-/Linux-služby, integrace.
• Build & Release: CI/CD, správa artefaktů, podepsané instalátory, rollback.

Důležité: Tyto body by měly být ideálně implementovány po oddělení a zabezpečení – teprve pak lze změny bezpečně verifikovat.

Kompletní přepsání je v některých případech smysluplné – často je to ale nejdražší cesta k získání „moderní technologie“. Tyto otázky pomohou při zařazení:

• Je obchodní logika kompletně pochopena a testovatelná – nebo je mnoho znalostí implicitně v provozu?
• Existují tvrdé termíny (např. ukončení platformy, compliance), které vylučují paralelní provoz?
• Jak velká je rozmanitost variant (zákaznická/mandantní logika)?
• Jak kritická je dostupnost a jak vysoká je tolerance vůči změnám procesů?
• Které části jsou skutečně „viníkem“ (UI, přístup k datům, integrace, nasazení) – a které jsou stabilní?

V mnoha B2B scénářích vede postupný přístup rychleji k měřitelným výsledkům, protože kontroluje rizika a chrání obchodní logiku.

Delphi-audit modernizace (pro procesně kritické aplikace): Analyzujeme architekturu, závislosti, oblasti rizik a dodáme prioritizovanou roadmapu, jak modernizovat, aniž by se ztratila obchodní logika.

• Vstup: kódová báze (read-only), nastavení buildu, 2–3 klíčové Use‑Cases, systémové prostředí (DB, integrace).
• Výsledek: mapa doménové logiky/modulů, analýza rizik a závislostí, doporučená cílová architektura, plán realizace v inkrementech včetně zajištění (testy/parallelní provoz).
• Volitelně: Proof of Concept pro odpojení + první Golden-Master test.

Tak získáte spolehlivý podklad pro rozhodnutí, než se rozpočet a čas vloží do riskantního přepsání.

Lze Delphi modernizovat, aniž by se aplikace přepisovala?
Ano. V mnoha případech se nejprve oddělí doménová logika od přístupu k datům a následně se provede technická modernizace. To snižuje riziko a udržuje provoz stabilní.

Jak zabránit tomu, aby byla doménová logika „potichu“ měněna?
Pomocí Golden-Master-/regresních testů, telemetrie a kontrolovaného paralelního provozu s jasnou rollback-strategií.

Které kroky často přinesou nejrychlejší přínos?
Transparentnost (Assessment), oddělení UI/SQL, nahrazení BDE a vrstva API/služeb pro integrace – vždy zajištěné testy.

Jak dlouho trvá modernizace?
To závisí na kritických případech použití, různorodosti variant a závislostech. Audit obvykle v krátké době poskytne spolehlivou roadmapu a prioritizované inkrementy.