Модернізувати Delphi, не втрачаючи бізнес-логіки

Delphi-застосунки в багатьох компаніях працюють стабільно роками й відтворюють саме ту доменну логіку, яка забезпечує доходи, якість сервісу та відповідність вимогам. Тому модернізація рідко полягає в «новому інтерфейсі», натомість мова про контрольовану еволюцію, за якої зберігаються правила, виняткові випадки та історичні знання про процеси.

У цьому матеріалі ми показуємо перевірений підхід до поетапної модернізації Delphi: від інвентаризації через відокремлення UI/доступу до даних до технічної модернізації (Unicode/64‑Bit, BDE-Ablösung, API/Services) — включно із захистом через тести, моніторинг і паралельну експлуатацію. Мета — архітектура, придатна до модернізації, без повного одноетапного переписування та без втрати логіки.

Модернізації в практиці рідко зазнають поразки через компілятор чи фреймворк, натомість через хибні припущення про поведінку системи. Протягом років сформовані Delphi-застосунки зазвичай містять доменну логіку в обробниках GUI, SQL у логіці форм, варіації на рівні клієнта/тенанта, історично зумовлені особливі випадки та інтеграції, задокументовані лише «в експлуатації».

Повне одноразове переписування (Big-Bang-Rewrite) змушує наново реконструювати ці знання — включно з помилками, які легасі-система вже давно не робить. Кращий підхід — розглядати доменну логіку як актив: ізолювати, захистити, а потім крок за кроком модернізувати.

Реалістичне цільове уявлення для процесо‑критичних B2B-систем — не «все нове», а архітектура, яка дозволяє зміни без загрози для поточної експлуатації:

• чітке розмежування UI, доменної логіки, доступу до даних та інтеграцій
• тестованість та вимірюваність (Regression, Logging, Monitoring, reproduzierbare Builds)
• поетапна замінюваність (UI модернізувати без негайної міграції БД — або навпаки)
• API-здатність (зокрема REST), щоб підключати портали, мобільні клієнти чи системні інтеграції
• експлуатаційні розгортання з можливістю відкату

Delphi для цього підходить добре, оскільки існуючі Units і доменні класи можна повторно використовувати, модернізуючи периферію.

Перш ніж змінювати код, потрібна надійна основа для прийняття рішень — не повна документація. Ефективними виявилися ці три результати:

• Карта доменної логіки: критичні Use-Cases, правила/розрахунки, варіанти (тенанти/країни/клієнти), інтерфейси, джоби/пакетні запуски.
• Профіль ризиків: особливо критичні до помилок області, якість даних, регуляторні вимоги, вузькі місця в експлуатації (Performance, Stabilität, Wartbarkeit).
• Беклог модернізації: пріоритизовані пакети за бізнес‑цінністю та ризиком (що має залишатися стабільним, що може змінитися, що — пізніше).

Це робить модернізацію планованою: чіткими інкрементами замість єдиного проекту «все-або-нічого».

Щоб доменна логіка не змінилася «випадково», потрібен захист, який працює незалежно від рефакторингу UI. Типові складові:

• Characterization/Golden-Master-Tests: наявну поведінку фіксують за допомогою репрезентативних входів/виходів (звіти, розрахунки, кроки процесу).
• Регресійні тести на рівні Use-Case: критичні бізнес‑процеси відтворюються автоматизовано або напівавтоматизовано.
• Телеметрія: логування, метрики та профілі помилок роблять порівнюваними до/після зміни.
• Parallelbetrieb & kontrollierte Umstellung: нові модулі працюють поруч із наявною системою (Feature Toggles, пілотні групи), з чіткою стратегією відкату.

Тільки коли ці страхувальні сітки створені, має сенс власне технічне оновлення — оскільки ризик і доопрацювання різко зменшуються.

Найпоширеніша причина втрати логіки — це змішування UI, доступу до даних і предметних правил. Модернізація тому починається з відокремлення компонентів — а не з заміни UI‑фреймворку.

Практична ціль — структура з 3 шарів:

• Presentation: VCL/FMX, Presenter/ViewModel, лише валідація, близька до UI (формат, обов’язкові поля)
• Business: доменні моделі, сервіси, правила, логіка станів, розрахунки
• Data/Integration: репозиторії, доступ до БД, адаптери до ERP/DMS/CRM, REST-клієнти, messaging

Практичне правило: предметні правила переміщуються з OnClick/OnExit у доменні сервіси. SQL переміщується з форм у репозиторії. Тоді логіка стає тестованою і пізніше може повторно використовуватись через UI, сервіси та джоби.

За шаблоном Strangulation Pattern нове спеціально реалізується «поряд» з існуючою системою: нові функції вже імплементуються в відокремленій структурі, поки legacy-система продовжує працювати. Крок за кроком новий шар бере на себе більше відповідальності, поки старі частини не відпадуть.

Приклад (типово для B2B):

• Ви екстрагуєте логіку обробки замовлень у доменний сервіс.
• Існуючий VCL-UI спочатку використовує той же сервіс (без розриву процесу).
• Паралельно з’являється REST-ендпойнт для порталу клієнта або інтеграції.
• Після стабілізації окремі старі форми замінюються — без необхідності будувати основну логіку заново.

Таким чином ви знижуєте ризики проєкту, зберігаєте працездатність і швидко отримуєте вимірювану користь (наприклад API, продуктивність, підтримуваність).

Залежно від вихідної ситуації ці блоки часто мають значення — вирішальним є пріоритизація за ризиком і бізнес-цінністю:

• BDE/відключення доступу до Legacy-DB: сучасні драйвери/провайдери, чіткі межі транзакцій, відтворювані розгортання.
• Unicode: обробка рядків, база даних/інтерфейси, сторонні компоненти.
• 64‑Bit: залежності, пам’ять/продуктивність, зовнішні бібліотеки.
• Шар API і сервісів: REST, Windows-/Linux-сервіси, інтеграції.
• Build & Release: CI/CD, менеджмент артефактів, підписані інсталятори, відкат.

Важливо: ці пункти бажано реалізовувати після відокремлення та страхування — тоді зміни можна безпечно верифікувати.

Повний перепис у деяких випадках є виправданим — але часто це найдорожчий шлях отримати «сучасну технологію». Ці питання допоможуть при класифікації:

• Чи предметна логіка повністю зрозуміла і тестована — чи багато знань приховано в експлуатації?
• Чи існують жорсткі дедлайни (наприклад кінець підтримки платформи, відповідність), які виключають паралельну експлуатацію?
• Який рівень варіативності (логіки по клієнтах/мандантам)?
• Наскільки критична доступність і яка толерантність до змін процесів?
• Які частини справді «винні» (UI, доступ до даних, інтеграції, деплоймент) — а які стабільні?

У багатьох B2B-сценаріях поетапний підхід швидше дає вимірювані результати, оскільки контролює ризики і захищає предметну логіку.

Delphi-Modernisierungs-Audit (для процесно-критичних застосунків): Ми аналізуємо архітектуру, залежності, зони ризику і надаємо пріоритизовану дорожню карту, як модернізувати, не втрачаючи предметної логіки.

• Вхідні дані: кодова база (read-only), налаштування збірки, 2–3 ключові сценарії використання, середовище системи (DB, інтеграції).
• Результат: карта логіки/модулів, аналіз ризиків та залежностей, рекомендована цільова архітектура, план реалізації по інкрементах включно із заходами забезпечення (тести/паралельна експлуатація).
• Опційно: Proof of Concept для відокремлення та перший Golden-Master-тест.

Так ви отримаєте надійну основу для прийняття рішень, перш ніж бюджет і час будуть витрачені на ризикове переписування.

Чи можна Delphi модернізувати, не переписуючи застосунок?
Так. У багатьох випадках спочатку відокремлюють бізнес-логіку та доступ до даних, а потім виконують технічну модернізацію. Це знижує ризики і підтримує стабільність експлуатації.

Як запобігти тому, щоб бізнес-логіку «непомітно» змінювали?
За допомогою Golden-Master-/регресійних тестів, телеметрії та контрольованої паралельної експлуатації з чіткою стратегією відкату.

Які кроки часто приносять найшвидший ефект?
Прозорість (оцінка), відокремлення UI/SQL, заміна BDE та шар API/сервісів для інтеграцій — кожен з цих кроків підкріплюється тестуванням.

Скільки часу займає модернізація?
Це залежить від критичних сценаріїв використання, розмаїття варіантів та залежностей. Аудит зазвичай у короткий термін дає надійну дорожню карту та пріоритезовані інкременти.