Багато компаній роками або десятиліттями експлуатують стабільні Delphi-додатки, що відтворюють ядро їхніх процесів: обробка замовлень, виробництво, сервіс, логістика, розрахунки, управління обладнанням, документообіг. У цих системах міститься не лише код, а й надійна взаємодія бізнес-правил, моделі даних, користувацьких сценаріїв і досвіду експлуатації. Саме це ускладнює модернізацію: справжня цінність рідко знаходиться в інтерфейсі, найчастіше вона в накопиченій предметній логіці.
Якщо модернізацію розуміти як «побудувати заново», втрата майже неминуча. Не тому, що нові технології погані як такі, а тому, що імпліцитні знання з успадкованої системи — особливі випадки, історичні дані, винятки в процесах, регуляторні деталі — при перенесенні часто не відтворюються повністю. Результат: дорогі регресійні помилки, змінені часи виконання процесів, проблеми з прийняттям і проекти, що тривають довше за план.
Delphi однак дуже добре піддаються модернізації без втрати предметної логіки. Ключ — контрольований покроковий підхід: спочатку створити прозорість (архітектура, дані, ризики), потім розрізнити компоненти (UI, доступ до даних, доменна логіка), далі модернізувати (драйвери баз даних, Unicode/64-біт, API, сервіси, мультиплатформеність) — і при цьому забезпечити безперервність експлуатації. Цей матеріал описує практичні шаблони модернізації, типові підводні камені та підхід, який працює в B2B-середовищах з високою критичністю процесів.
Чому модернізація Delphi рідко є «тільки технічним» проєктом
У реальності модернізації зазвичай не зриваються через відсутність прапорця компілятора, а через хибні припущення про поведінку системи. Delphi-додатки, які розширювалися роками, часто містять:
- Бізнес-правила в подіях GUI (OnClick, OnExit, OnValidate), часто розкидані по багатьох формах
- SQL-запити «біля поверхні», оптимізовані протягом років під одну конкретну базу даних
- Обходи для історичних даних, особливих випадків, варіантів клієнтів або логіки мульти-tenant
- Батч-процеси, що запускаються у фіксований час і мають залежності
- Інтеграції з ERP, DMS, CRM або машинами, які майже не документовані
- Приховані знання у вигляді експлуатаційних рутин: «Якщо помилка X, то спочатку перевірити Y»
Хто починає з Big-Bang-перепису, змушений відтворювати всі ці знання заново — разом із помилками, від яких стара система вже давно звільнилася. Кращий підхід — розглядати предметну логіку як актив: спочатку ізолювати, потім захистити, потім модернізувати.
Модернізація без втрати логіки: цільове бачення та принципи
Життєздатне цільове бачення для B2B-систем — це не «усе нове», а архітектура, що дозволяє змінюватися. Типові властивості:
- Розмежування відповідальностей (UI, домен/предметна логіка, доступ до даних, інтеграції)
- Тестованість і вимірюваність (регресійні тести, логування, моніторинг, відтворювані збірки)
- Поступова замінюваність (оновити UI без негайної перебудови моделі даних; мігрувати БД без перепису UI)
- API-готовність (REST-Server або шар сервісів для підключення порталів, мобайлу, інтеграцій)
- Операційна придатність (Windows- та Linux-Services, чіткі деплойменти, стратегія відкату)
У Delphi це особливо досяжно, оскільки можна повторно використовувати наявні Units і доменні класи, модернізуючи лише периферію: доступ до даних від BDE до BDE-Ablösung mit nativer Anbindung, нові REST-ендпоїнти, нові UI-модулі, нові деплойменти.
Інвентаризація: що насправді потрібно зберегти?
Перед тим як «чіпати» код, доцільна структурована інвентаризація. Мета — не повна документація, а надійна база для прийняття рішень.
1) Мапа предметної логіки замість марафону читання коду
Практично виправданим виявився підхід зі створенням мапи предметної логіки з такими перспективами:
- Use-Cases: Які ключові процеси критичні для бізнесу? (наприклад, створення замовлення, рахунок, сторно, повернення, сервісне обслуговування машин, договір обслуговування)
- Правила: Які валідації, обчислення, автомати станів існують?
- Варіанти: Мульти-tenant, конфігурації клієнтів, національні правила
- Інтерфейси: Імпорт/експорт, ERP/DMS/CRM, пристрої/протоколи
- Batch/Jobs: нічні запуски, звіти, синхронізації даних
З цієї мапи формуються пріоритетні пакети модернізації: що має залишатися стабільним, що може змінитися, що відкласти на потім.
2) Зробити видимими технічні борги
Типові технічні борги в старіших Delphi-системах:
- Borland BDE/Paradox-залежності
- ANSI-рядки/відсутня Unicode-міграція
- Лише 32-біт, застарілі сторонні компоненти
- Монолітна логіка форм, глобальні змінні, Units з побічними ефектами
- Нечіткі межі транзакцій та «SQL скрізь»
Мистецтво полягає не в догматичному «виправленні» всього цього, а в розстановці пріоритетів, що мінімізують ризик і максимізують бізнес-цінність.
Архітектурна розв’язка: важіль проти втрати логіки
Найчастіша причина втрати логіки — змішування UI, доступу до даних і бізнес-правил. Тому модернізація починається з розв’язки залежностей — не з «нового UI-фреймворка».
Layer-3 архітектура як прагматичний цільовий стан
Для багатьох успадкованих Delphi-застосунків добре підходить Layer-3 Architektur:
- Presentation Layer: VCL/FMX-формы, ViewModels/Presenter, валідація лише близько до UI (формат, обов’язкові поля)
- Business Layer: доменні моделі, сервіси, правила, логіка станів, обчислення
- Data/Integration Layer: репозиторії, SQL/ORM-частини, адаптери інтерфейсів, REST-клієнти, messaging
Перевага: предметна логіка стає тестованою та повторно використовуваною. Пізніше клієнтський портал, REST-Server або Linux-сервіс можуть використовувати ті самі доменні сервіси. Таким чином ви модернізуєте «зовнішній шар», не перевинаходячи ядро логіки.
Strangulation Pattern: поступове «обіймання» старої системи
Перевірений шаблон міграції — Strangulation Pattern: нові функції реалізуються вже в новій структурі (наприклад, доменний сервіс + репозиторій), тоді як існуючі форми поступово перебудовуються. Стара система залишається працездатною, але крок за кроком заміщається новою.
Важливо активно змінювати залежності: не «форма викликає SQL», а «форма викликає сервіс», і сервіс вирішує. Ця невелика інверсія часто дає найбільший ефект.
Модернізація доступу до даних: BDE-Ablösung та планування FireDAC
Ключовий крок модернізації — BDE-Ablösung. Компанії часто недооцінюють, що справа не лише в драйверах, а й у семантиці SQL, транзакціях, блокуваннях, типах даних і поведінці при помилках. Сучасні Delphi-стеки зазвичай орієнтовані на BDE-Ablosung mit nativer Anbindung з нативними драйверами (наприклад для MariaDB/MySQL, PostgreSQL, SQL Server).
Що справді вирішується при переході
- Цільова СУБД: Залишається поточна БД? Чи має сенс міграція БД (наприклад, з Paradox/Firebird до MariaDB або PostgreSQL)?
- Модель транзакцій: Де починаються/закінчуються транзакції? Які кейси мають бути атомарними?
- Конкурентність/блокування: Оптимістична проти песимістичної, робота з deadlock, стратегії retry
- SQL-діалект: Функції роботи з датами, поведінка рядків, обробка NULL, регістрочутливість
- Продуктивність: Індекси, плани запитів, пагінація, пакетні вставки
Предметна логіка тісно залежить від поведінки даних. Хто мігрує «краєм ока», ризикує отримати тонкі відхилення на практиці: округлення, сортування, межі дат, конфлікти блокувань. Тому рівень даних має бути включений у план модернізації з самого початку, включно зі шляхом міграції та стратегією тестових даних.
Прагматичні кроки до FireDAC-міграції
Замість тотального перепису вигідною виявляється така послідовність:
- Впровадження шару доступу до даних (Repository/DAO) як фасади
- Переведення окремих Use-Cases на FireDAC (наприклад, спочатку «читання», пізніше — «запис»)
- Уніфікація обробки з’єднань, обробки помилок, логування
- Поступове відключення BDE-компонентів, коли фасад стабільний
Так застосунок залишається в будь-який момент працездатним, і ви уникаєте довгого періоду «напівзакінченості».
Unicode, 64-біт і залежності: детальні пастки модернізації
Багато модернізацій ламаються не через концепцію, а через недооцінені деталі. Три такі теми особливо поширені в Delphi-проєктах.
Unicode-міграція: не лише рядки, а й потоки даних
В дуже старих версіях Delphi системи походять з ANSI-світу. Unicode-міграція зачіпає:
- Типи рядків і конвертації (WideString/AnsiString/UnicodeString)
- Обробку файлів та шляхів (Windows-API, мережеві шляхи)
- Імпорт/експорт (CSV, фіксована довжина полів, EDI, успадковані інтерфейси)
- Сортування/колація в базі даних
Важливо ідентифікувати критичні потоки даних (наприклад, тексти рахунків, найменування товарів, міжнародні адреси) і створити для них регресійні тести. Unicode — це радше суцільний процес якості, ніж окремий «рефакторинг».
Переход на 64-біт: пам’ять — не єдина проблема
Перехід на 64-біт часто спрощено звужують до «розміру вказівника». На практиці значущими є:
- Застарілі сторонні компоненти без підтримки 64-біт
- COM/ActiveX-залежності
- DLL і драйвери (штрих-код, пристрої, криптографія, підпис)
- Інсталятор/деплой та реєстрові шляхи (WOW64)
Розумна стратегія — спочатку інвентаризувати всі зовнішні залежності та визначити альтернативи. Тоді крок до 64-біт стає планованим і не перетворюється на неприємний сюрприз перед релізом.
Windows 11 ARM64: перевірити раніше, ніж платити потім
З появою Windows 11 ARM64 виникає новий клас цільових систем. Навіть якщо не кожна компанія одразу потребує нативних ARM64-збірок, розумно перевірити це раніше:
- Чи є нативні залежності (DLL, драйвери), що не працюватимуть під ARM64?
- Чи покладається застосунок на емуляцію, і чи це прийнятно?
- Як виглядає інсталятор, як оновлення/відновлення?
У проєктах модернізації це типова «пізня» тема, яка стає дорогою. Краще: включити її в дорожню карту платформи і технічно відпрацювати на ранньому етапі.
REST-Server і сервіси: зробити предметну логіку доступною для порталів та інтеграцій
Багато компаній модернізують Delphi не тому, що десктоп-додаток «виглядає старим», а через нові вимоги: клієнтський портал, доступи для партнерів, мобільні процеси, інтеграція з ERP/DMS/CRM, конвеєри звітності. Для цього потрібні чіткі інтерфейси. REST-Server часто є практичним містком.
API перш за все? Лише якщо права та доменна логіка йдуть разом
API дає користь лише тоді, коли вона забезпечує ту саму предметну логіку, що й клієнт. Інакше з’являються два набори правил: один у десктопі, інший у бекенді. Наслідки — невідповідності та вразливості.
Тому REST-Server має найкраще накладатися безпосередньо на доменні сервіси. Типові складові:
- Аутентифікація/авторизація (ролі, мульти-tenant, права)
- DTO/серіалізація з чіткими правилами версіонування
- Підхід до транзакцій і помилок (HTTP-статуси, Problem-Details, логування)
- Ідемпотентність і конкурентність (для retry, обробки черг)
Таким чином REST-Server стає стабільною точкою інтеграції — а не «ще одним клієнтом».
Модернізувати Linux-Services і Windows Services
Батч-процеси та інтеграції в багатьох компаніях працюють як Windows Services, завдання планувальника або навіть «приховані» десктоп-інстанції. При модернізації корисна консолідація:
- Відділення UI та фонового виконання логіки
- Конфігуровані розклади виконання і чіткі експлуатаційні параметри
- Чисте логування (структуровані логи, кореляція по Job/Request)
- Опція запускати сервіси як Linux (наприклад, для контейнеризованих деплойментів)
Перевага не лише в «модності», а в операційній надійності: відтворюваний запуск, менше ручних втручань, простіший пошук помилок.
Модернізувати UI, не чіпаючи ядро: VCL, FMX та гібридні підходи
Багато планів модернізації починаються з UI. Це може мати сенс — якщо чітко зрозуміти очікувану вигоду. Якщо предметна логіка розв’язана, UI можна оновлювати значно з меншим ризиком.
Поступова модернізація VCL-застосунків
VCL у багатьох B2B-сценаріях й досі є надійним вибором, особливо в середовищах з інтенсивною Windows-роботою та високою продуктивністю на десктопі. Під модернізацією маються на увазі такі кроки:
- Зменшення UI-логіки (Presenter/ViewModel), переміщення предметних правил у сервіси
- Очищення ландшафту компонентів, консолідація власних контролів
- Покращення відчуття відгуку (async, фонова робота, індикатори прогресу, Cancel)
- Доступність інтерфейсу, консистентна валідація, зрозуміліші повідомлення про помилки
Це дає відчутний ефект без перепису всієї оболонки.
Delphi Multiplattform: коли FMX має сенс
Якщо є реальні мультиплатформені вимоги (Windows, macOS, можливо Linux у контексті сервісів), FMX може бути варіантом. Вирішальною є очікувана вартість: мультиплатформа вимагає додаткових тестів і інтеграційної роботи (шрифти, друк, системні діалоги, файлові системи, пакування/деплой). Витрати добре прогнозуються, коли предметна логіка вже винесена в чистий шар.
Прийнятний практичний шлях часто гібридний: VCL залишається для Windows-клієнта, а нові фронтенди (портал, мобільний застосунок) підключаються через REST-Server. Таким чином мультиплатформеність досягається через межі системи, а не через єдиний UI-стек.
Тестування та регресія: як «закріпити» предметну логіку
«Втратити предметну логіку» на практиці означає: система в граничних випадках дає інші результати. Це рідко помітно відразу, але дорого. Тому тестованість — не розкіш, а інструмент модернізації.
Золоті Use-Cases і еталонні дані
Виправданим є набір «золотих» Use-Cases: реальні критичні процеси з визначеною початковою даними та очікуваним результатом (наприклад, ланцюжок документів від пропозиції до кредит-ноти, або наряд на обслуговування з запасними частинами і обліком часу). Вони стають регресійними тестами або принаймні повторюваними тестовими сценаріями.
Важливо: не лише шляхи успіху, а й типові шляхи помилок (конфлікти блокувань, відсутні права, неповні майстер-дані, дубльований файл імпорту).
Автоматизація там, де вона дає найбільший ефект
Не кожен спадковий проєкт потребує одразу 80% покриття юніт-тестами. Високий ROI часто дають тести для:
- Доменних сервісів (обчислення, правила, переходи станів)
- Доступу до даних з чіткими контрактами (мапінг, SQL, транзакції)
- API-тестів (аутентифікація, права, версіонування)
Мета — стабільність при змінах, а не академічні метрики.
Практичний підхід: дорожня карта модернізації по етапах
З B2B-позиції модернізація має залишатися постачальною. Типова дорожня карта, орієнтована на ризики:
Етап 1: Аналіз, цільова архітектура, швидкі виграші (2–6 тижнів)
- Карта системи (модулі, бази даних, інтерфейси, задачі, залежності)
- Матриця ризиків (BDE, сторонні постачальники, 32/64-біт, Unicode, деплой)
- Визначення цільової архітектури (Layer-3, шар сервісів, API-стратегія)
- Quick Wins: стабілізувати процес збірки, покращити логування, впорядкувати версійний контроль
Етап 2: Розв’язка предметної логіки (поновлювано, інкрементально)
- Ідентифікувати доменні сервіси і винести їх з форм
- Впровадити фасади-репозиторії
- Перші регресійні тести для критичних Use-Cases
Етап 3: Модернізація доступу до даних/DB-шару
- Впровадити FireDAC, встановити концепт з’єднань і транзакцій
- BDE-Ablösung по модулях (або міграція БД з паралельним режимом роботи)
- Тестування продуктивності та поведінки блокувань під навантаженням
Етап 4: Додати REST-Server і інтеграції
- API з аутентифікацією, правами, версіонуванням
- Підключити портали/інтеграції без дублювання логіки
- Консолідувати сервіси для батчів та фонового виконання
Етап 5: Платформа та UI-рішення (64-біт, ARM64, мультиплатформа)
- 64-біт збірка, заміна залежностей
- Перевірка/планування сумісності з ARM64
- UI-модернізація: оновлення VCL або FMX/гібрид, на підставі бізнес-користі
Послідовність свідома: спочатку ви отримуєте прозорість, потім стабілізуєте ядро і лише після цього масштабно впроваджуєте «помітні» зміни. Це зменшує ризики і робить експлуатацію прогнозованою.
Типові антишаблони: що робить модернізацію зайво дорогою
Деякі патерни постійно зустрічаються в аудитах і проектах-рятувальниках:
- «Ми будуємо заново і беремо тільки фічі»: майже завжди призводить до втрати логіки, бо пропускаються особливі випадки.
- API як паралельний світ: бізнес-правила залишаються в клієнті, а бекенд винаходить їх заново.
- Заміна БД без семантичних тестів: ті самі дані — інша поведінка (NULL, сортування, логіка дат).
- Занадто пізнє управління залежностями: 64-біт/ARM64 зазнає фіаско через маленьку DLL перед Go-Live.
- «Рефакторинг спочатку» без цільового образу: багато змін, мало вимірного ефекту, велика регресія.
Протидія завжди одна: спочатку прояснити цільову архітектуру і ризики, потім інкрементально перебудовувати, тестуючи і роблячи предметну логіку видимою.
Висновок: модернізувати — означає зберегти й цілеспрямовано розширювати
Модернізація Delphi без втрати предметної логіки — це не протиріччя, а дисципліна. Компаніям не потрібно вибирати між «зберегти все» і «замінити все». Завдяки чіткому розділенню архітектури (наприклад, Layer-3), контрольованій BDE-Ablösung до FireDAC, API-стратегії через REST-Server та плану для Unicode, 64-біт і нових платформ як Windows 11 ARM64 можна поступово перевести вирослу систему в придатну для майбутнього архітектуру.
Ключовий момент — трактувати предметну логіку як головний актив: ізолювати, зробити тестованою, а потім модернізувати. Так виникає архітектура, що підтримує портали, сервіси і мультиплатформені вимоги, не ставлячи під загрозу поточну експлуатацію.
Якщо ви плануєте Delphi Modernisierung і хочете звести докупи предметну логіку, доступ до даних та експлуатацію — обговоріть з нами реалістичний шлях міграції: https://net-base-software-gmbh.de/kontakt/