Mnoho společností provozuje po léta či desetiletí stabilní Delphi-aplikace, které zobrazují jádro jejich procesů: vyřízení zakázek, výroba, servis, logistika, fakturace, správa zařízení, workflow dokumentů. V těchto systémech není jen kód, ale robustní souhra doménových pravidel, datového modelu, uživatelského vedení a provozních zkušeností. Právě to činí modernizaci náročnou: skutečná hodnota se zřídka nachází v uživatelském rozhraní, ale v narostlé doménové logice.
Pokud se modernizace chápe jako „postavit nově“, je ztráta předprogramována. Ne proto, že by nové technologie samy o sobě byly špatné, ale protože implicitní znalosti ze stávajícího systému – výjimky, historická data, procesní odchylky, regulatorní detaily – se při přesunu často plně nedají rekonstruovat. Výsledkem jsou nákladné regresní chyby, změněné časy procesů, problémy s akceptací a projekt, který běží déle než plánovaně.
Delphi se však velmi dobře modernizuje, aniž by došlo ke ztrátě doménové logiky. Klíčem je kontrolovaný, postupný přístup: nejprve vytvořit transparentnost (architektura, data, rizika), pak oddělit zodpovědnosti (UI, přístup k datům, doménová logika), následně modernizovat (ovladače databází, Unicode/64‑bit, API, služby, multiplatformnost) – a současně zajistit běžný provoz. Tento příspěvek popisuje prakticky ověřené vzory modernizace, typické nástrahy a postup, který funguje v B2B prostředích s vysokou procesní kritičností.
Proč modernizace Delphi zřídka bývá pouze „technický projekt“
V praxi modernizace selhávají nikoli kvůli chybějícímu přepínači překladače, ale kvůli chybným předpokladům o chování systému. Delphi aplikace, které se v průběhu let rozšiřovaly, často obsahují:
- doménová pravidla v GUI událostech (OnClick, OnExit, OnValidate), často rozptýlená přes mnohé formy
- SQL příkazy „blízko povrchu“, roky optimalizované pro přesně jednu databázi
- obcházení pro historická data, speciální případy, zákaznické varianty nebo mandantovou logiku
- batch procesy, které v praxi běží v pevně stanovených časech a mají vzájemné závislosti
- integrace do ERP, DMS, CRM nebo strojů, které jsou málo dokumentované
- tiché znalosti ve formě provozních rutin: „pokud chyba X, nejdříve zkontrolovat Y“
Kdo zde začne s Big‑Bang přepsáním, musí veškeré tyto znalosti znovu vytvořit – včetně chyb, které staré řešení už dlouho neprovádí. Lepší přístup je považovat doménovou logiku za aktivum: nejprve izolovat, pak zabezpečit, následně modernizovat.
Modernizace bez ztráty logiky: cílový obraz a zásady
Udržitelný cílový obraz pro B2B systémy není „vše nové“, ale architektura, která umožňuje změny. Typické vlastnosti:
- Oddělené odpovědnosti (UI, doména/doménová logika, přístup k datům, integrace)
- Testovatelnost a měřitelnost (regresní testy, logování, monitoring, reprodukovatelné buildy)
- Postupná zaměnitelnost (modernizovat UI bez okamžitého přebudování datového modelu; migrovat DB bez přepisování UI)
- API schopnost (REST‑Server nebo servisní vrstva pro připojení portálů, mobilních aplikací, integrací)
- Provozuschopnost (Windows‑ a Linux‑services, jasné deploymenty, rollback strategie)
U Delphi je to zvláště dosažitelné, protože lze nadále využívat existující jednotky a doménové třídy, zatímco se okolo vnějších vrstev provádí modernizace: přístup k datům od BDE směrem k BDE‑Ablösung s nativním napojením, nové REST endpointy, nové UI moduly, nové deploymenty.
Inventura: co je skutečně nutné zachovat?
Než se „sáhne“ do kódu, vyplatí se strukturovaná inventura. Cílem není úplná dokumentace, ale robustní rozhodovací podklad.
1) Mapa doménové logiky místo maratonského čtení kódu
Osvedčeným postupem je mapa doménové logiky s následujícími perspektivami:
- Use‑cases: Které klíčové procesy jsou obchodně kritické? (např. vytvoření zakázky, faktura, storno, vrácení zboží, servis stroje, servisní smlouva)
- Pravidla: Jaké validace, výpočty, stavové automaty existují?
- Varianty: Mandanti, zákaznické konfigurace, země‑specifická pravidla
- S rozhraní: Import/export, ERP/DMS/CRM, zařízení/protokoly
- Batch/Joby: noční běhy, reporty, datové srovnání
Z této mapy vzejdou prioritní balíčky modernizace: co musí zůstat stabilní, co se může změnit, co může být odloženo.
2) Zviditelnit technický dluh
Typické technické dluhy ve starších Delphi systémech:
- Borland BDE/Paradox závislosti
- ANSI‑řetězce/chybějící Unicode migrace
- Výhradně 32‑bit, zastaralé komponenty třetích stran
- Monolitická logika formulářů, globální proměnné, jednotky s vedlejšími efekty
- Nejasné hranice transakcí a „SQL všude“
Umění spočívá v tom, tyto body neideologicky „odstranit“, ale seřadit je do sekvence, která minimalizuje riziko a maximalizuje byznys hodnotu.
Architektonické oddělení: páka proti ztrátě logiky
Nejčastější příčinou ztráty logiky je promísení UI, přístupu k datům a doménových pravidel. Modernizace proto začíná oddělením – nikoli volbou nového UI frameworku.
Layer-3 architektura jako pragmatický cílový stav
Pro mnoho existujících Delphi aplikací funguje velmi dobře Layer-3 architektura:
- Presentation Layer: VCL/FMX formuláře, ViewModels/Presentery, validace omezená na UI (formát, povinná pole)
- Business Layer: doménové modely, služby, pravidla, stavová logika, výpočty
- Data/Integration Layer: repository, SQL/ORM části, adaptory rozhraní, REST klienti, messaging
Přidaná hodnota: doménová logika je testovatelná a znovupoužitelná. Později může klientský portál, REST‑Server nebo Linux‑service používat přesně ty samé doménové služby. Tím modernizujete „vnější plášť“, aniž byste znovu vynalézali jádro logiky.
Strangulation Pattern: postupné „obkročení“ starého systému
Ověřený migrační vzor je Strangulation Pattern: nové funkce vznikají již v nové struktuře (např. doménový servis + repository), zatímco existující formy se postupně přepisují. Starý svět zůstává funkční, ale kus po kusu je nahrazován tím novým.
Důležité je aktivně převracet závislosti: nikoli „forma volá SQL“, ale „forma volá servis“, a servis rozhoduje. Tento malý obrat je často největší přínos.
Modernizace přístupu k datům: BDE‑Ablösung a plánování FireDAC
Centrálním krokem modernizace je BDE‑Ablösung. Společnosti často podceňují, že nejde jen o ovladače, ale o SQL sémantiku, transakce, zamykání, datové typy a chování při chybách. Moderní Delphi stacky obvykle sází na BDE-Ablosung mit nativer Anbindung s nativními ovladači (např. pro MariaDB/MySQL, PostgreSQL, SQL Server).
Co se při přechodu skutečně rozhoduje
- Cílová databáze: Zůstává stávající DB? Má smysl přechod na jinou DB (např. z Paradox/Firebird na MariaDB nebo PostgreSQL)?
- Transakční model: Kde začínají/končí transakce? Které use‑case musí být atomické?
- Souběžnost/zamykání: Optimistické vs. pesimistické, práce s deadlocky, retry strategie
- SQL dialekt: Datové funkce, chování řetězců, NULL handling, case‑senzitivita
- Výkon: Indexy, plány dotazů, strankování, hromadné vkládání
Doménová logika je úzce vázaná na chování dat. Kdo migraci odkládá do pozadí, riskuje v praxi jemné odchylky: zaokrouhlování, řazení, hranice datumu, konflikty zámků. Proto patří datová vrstva brzy do modernizačního plánu, včetně migrační cesty a strategie testovacích dat.
Pragmatické kroky k FireDAC migraci
Místo kompletního přepisu aplikace naráz se osvědčila tato pořadí:
- zavedení vrstvy přístupu k datům (Repository/DAO) jako fasády
- přepínání jednotlivých use‑case na FireDAC (např. nejdříve čtení, později zápis)
- sjednocení řízení spojení, zpracování chyb, logování
- postupné odstavování BDE komponent tam, kde je fasáda stabilní
Tím aplikace zůstává kdykoli dodavatelná a vy se vyhnete dlouhému období „polo‑hotového“ stavu.
Unicode, 64‑bit a závislosti: modernizační nástrahy v detailech
Mnohé modernizace nepadnou na konceptech, ale na podceněných detailech. Tři z nich se v Delphi projektech vyskytují obzvlášť často.
Unicode migrace: ne jen řetězce, ale datové toky
Ve velmi starých verzích Delphi systémy vycházejí ze světa ANSI. Unicode migrace se týká tehdy:
- typů řetězců a konverzí (WideString/AnsiString/UnicodeString)
- práce se soubory a cestami (Windows‑API, síťové cesty)
- importu/exportu (CSV, pevné délky polí, EDI, legacy rozhraní)
- řazení/kódování v databázi
Rozhodující je identifikovat kritické datové toky (např. texty faktur, názvy položek, mezinárodní adresy) a pro ně nastavit regresní testy. Unicode není jen „přestavba“, ale průběžný proces kvality.
Přechod na 64‑bit: paměť není jediné téma
Přechod na 64‑bit se často redukuje na „velikost ukazatelů“. V praxi jde spíše o:
- zastaralé komponenty třetích stran bez 64‑bit podpory
- COM/ActiveX závislosti
- DLL a ovladače (čárové kódy, zařízení, kryptografie, podpisy)
- instalátory/deployment a registry cesty (WOW64)
Smysluplná strategie je nejprve inventarizovat všechny externí závislosti a definovat alternativy. Poté je krok na 64‑bit plánovat – aby se nestal nepříjemným překvapením těsně před vydáním.
Windows 11 ARM64: zkontrolovat brzy, než zaplatíte pozdě
S Windows 11 ARM64 se objevuje nová třída cílových systémů. I když ne každá firma hned potřebuje nativní ARM64 buildy, je rozumné to včas ověřit:
- Existují nativní závislosti (DLL, ovladače), které na ARM64 neběží?
- Je aplikace závislá na emulaci, a je to přijatelné?
- Jak vypadá instalátor, jak aktualizace/opravování?
V modernizačních projektech je to typické „pozdí“ téma, které pak hodně stojí. Lepší je zařadit ho brzy do roadmapy platformy a technicky prověřit.
REST‑Server a služby: zpřístupnit doménovou logiku portálům a integracím
Mnoho firem nemodernizuje Delphi kvůli tomu, že desktopová aplikace „vypadá zastarale“, ale proto, že přicházejí nové požadavky: zákaznické portály, přístupy partnerů, mobilní procesy, integrace s ERP/DMS/CRM, reportingové pipeline. Potřebujete pro to jasná rozhraní. REST‑Server je často nejpraktičtějším mostem.
API nejdřív? Jen pokud přijdou i práva a doménová logika
API je přínosné jen tehdy, provádí‑li stejnou doménovou logiku jako klient. Jinak vzniknou dvě sady pravidel: jedna na desktopu, druhá v backendu. Důsledkem jsou nekonzistence a bezpečnostní díry.
Proto by REST‑Server vrstva měla co nejpříměji využívat doménové služby. Typické součásti:
- autentizace/autorizace (role, mandanti, práva)
- DTOs/serializace s jasnými pravidly verzování
- transakční a chybový koncept (HTTP statusy, Problem‑Details, logování)
- idempotence a souběžnost (pro retry, zpracování front)
Tím se REST‑Server stane stabilním integračním bodem – nikoli „druhým klientem“.
Modernizace Linux‑services a Windows služeb
Batch procesy a integrace v mnoha firmách běží jako Windows služby, úlohy plánovače nebo dokonce „skryté“ desktop instance. Při modernizaci se vyplatí konsolidace:
- oddělit UI a background logiku
- konfigurovatelné běhové plány a jasné provozní parametry
- čisté logování (strukturální logy, korelace podle jobu/požadavku)
- možnost provozovat služby pod Linux (např. pro kontejnerizované deploymenty)
Přínos není jen „moderní“, ale provozně praktický: reprodukovatelný provoz, méně manuálních zásahů, lepší diagnostika chyb.
Modernizace UI bez zásahu jádra: VCL, FMX a hybridní přístupy
Mnohé plány modernizace začínají u UI. To může dávat smysl – pokud je však jasné, co tím získáte. Pokud je doménová logika oddělena, lze UI renovovat s výrazně menším rizikem.
Postupná modernizace VCL aplikací
VCL je v mnoha B2B scénářích stále robustní volbou, obzvlášť pro Windows‑náročná prostředí s vysokou produktivitou na desktopu. Modernizace zde může znamenat:
- snížení UI logiky (Presenter/ViewModel), přesun doménových pravidel do služeb
- vyčištění komponentní krajiny, konsolidace vlastních kontrol
- zlepšení reaktivity (Async, background joby, progress, cancel)
- přístupnost, konzistentní validace, lepší chybové zprávy
Toto přinese hmatatelný užitek, aniž byste kompletně přepisovali UI.
Delphi multiplatforma: kdy dává smysl FMX
Pokud existují skutečné multiplatformní požadavky (Windows, macOS, případně Linux v kontextu služeb), může být FMX volba. Rozhodující je očekávání: multiplatformnost přináší dodatečnou testovací a integrační pracnost (fonty, tisk, OS dialogy, souborový systém, balení/deployment). Náklady jsou dobře odhadnutelné, pokud je doménová logika již v čisté vrstvě.
Častá pragmatická cesta je hybridní: VCL zůstane pro Windows klienta, zatímco nová frontendy (portál, mobilní aplikace) přistupují přes REST‑Server. Multiplatformnost tak vzniká přes hranice systému, nikoli jediným UI stackem.
Testování a regrese: jak „přibít“ doménovou logiku
„Ztratit doménovou logiku“ v praxi znamená: systém v okrajových případech vrací jiné výsledky. To není často okamžitě patrné, ale je nákladné. Proto není testovatelnost luxus, ale nástroj modernizace.
Zlaté use‑cases a referenční data
Osvedčilo se soubor „zlatých“ use‑case: reálné, kritické procesy s definovaným stavem dat a očekávanými výsledky (např. řetězec dokladů od nabídky po dobropis, nebo servisní zakázka s náhradními díly a časovými záznamy). Tyto scénáře se etablují jako regresní testy nebo alespoň jako opakovatelné testovací skripty.
Důležité: nejen úspěšné cesty, ale i typické chybové scénáře (konflikty zámků, chybějící oprávnění, neúplná master data, duplicitní importní soubor).
Automatizace tam, kde má největší efekt
Nevyžaduje každý provozní projekt okamžitě 80 % pokrytí unit testy. Vysoký ROI se často dosahuje u:
- doménových služeb (výpočty, pravidla, přechody stavů)
- přístupu k datům s jasnými kontrakty (mapování, SQL, transakce)
- API testů (auth, práva, verzování)
Cílem je stabilita při změnách, nikoli akademické metriky.
Postup v praxi: modernizační plán v etapách
Z pohledu B2B musí modernizace zůstat dodavatelná. Typický plán, který vychází z řízení rizik:
Etapa 1: Analýza, cílová architektura, okamžité přínosy (2–6 týdnů)
- mapa systému (moduly, databáze, rozhraní, joby, závislosti)
- riziková matice (BDE, třetí strany, 32/64‑bit, Unicode, deployment)
- definice cílové architektury (Layer-3, servisní vrstva, API strategie)
- okamžité přínosy: stabilizovat build proces, zlepšit logování, upravit verzovací systém
Etapa 2: Oddělení doménové logiky (probíhá inkrementálně)
- identifikovat doménové služby a vytáhnout je z formulářů
- zavést repository fasády
- první regresní testy pro kritické use‑case
Etapa 3: Modernizace přístupu k datům/DB vrstvy
- zavést FireDAC, etablovat koncept spojení a transakcí
- postupná BDE‑Ablösung (modulově nebo migration s paralelním provozem)
- testovat výkon a chování zámků pod zátěží
Etapa 4: Doplnit REST‑Server a integrace
- API s autentizací, právy, verzováním
- připojit portály/integrace bez duplikace logiky
- konsolidovat služby pro batch a background procesy
Etapa 5: Platformní a UI rozhodnutí (64‑Bit, ARM64, multiplatforma)
- 64‑bit build, výměna závislostí
- ověřit/naplánovat kompatibilitu ARM64
- UI modernizace: VCL refresh nebo FMX/hybrid, na základě byznys‑přínosu
Pořadí je zvoleno tak, abyste brzy získali transparentnost, poté stabilizovali jádro a až poté nasadili výrazné „viditelné“ změny. Tím klesá riziko a provoz zůstává plánovatelný.
Typické anti‑patterny: co modernizace zbytečně prodražuje
Některé vzory se v auditech a záchranných projektech opakují:
- „Postavíme nové a převezmeme jen funkce“: téměř vždy vede ke ztrátě logiky, protože chybí zvláštní případy.
- API jako paralelní svět: obchodní pravidla zůstávají na klientu a backend je vynaluje znovu.
- Databázová výměna bez semantických testů: stejná data, ale jiné chování (NULL, řazení, logika datumu).
- Příliš pozdní správa závislostí: 64‑bit/ARM64 selže na malé DLL těsně před Go‑Live.
- „Refactoring nejdřív“ bez cílového obrazu: mnoho změn, málo měřitelného přínosu, vysoká regrese.
Protikladem je vždy totéž: nejprve vyjasnit cílovou architekturu a rizika, pak inkrementálně přestavovat, současně testovat a zviditelňovat doménovou logiku.
Závěr: modernizovat znamená zachovat – a cíleně rozšiřovat
Modernizace Delphi bez ztráty doménové logiky není rozpor, ale disciplína. Firmy nemusí volit mezi „všechno zachovat“ a „všechno nahradit“. Se správným oddělením architektury (např. Layer-3), kontrolovanou BDE‑Ablösung směrem k FireDAC, API strategií přes REST‑Server a jasným plánem pro Unicode, 64‑bit a nové platformy jako Windows 11 ARM64 lze narostlý systém postupně převést do udržitelné struktury.
Klíčové je považovat doménovou logiku za jádrové aktivum: izolovat, učinit testovatelnou a teprve poté modernizovat. Tak vznikne architektura, která podporuje portály, služby a multiplatformní požadavky, aniž by ohrozila běžný provoz.
Plánujete‑li Delphi Modernisierung a chcete přitom doménovou logiku, přístup k datům a provoz smysluplně sloučit, proberte s námi realistickou migrační cestu: https://net-base-software-gmbh.de/kontakt/