Delphi модернизировать, не потеряв доменную логику

Delphi-Anwendungen laufen in vielen Unternehmen seit Jahren stabil – und bilden genau die Fachlogik ab, die Umsatz, Servicequalität und Compliance sichert. Bei einer Modernisierung geht es daher selten um „neue Oberfläche“, sondern um eine kontrollierte Weiterentwicklung, bei der Regeln, Sonderfälle und historisches Prozesswissen erhalten bleiben.

In diesem Beitrag zeigen wir ein praxiserprobtes Vorgehen, um Delphi schrittweise zu modernisieren: von der Bestandsaufnahme über die Entkopplung von UI/Datenzugriff bis zur technischen Modernisierung (Unicode/64‑Bit, BDE-Ablösung, API/Services) – inklusive Absicherung durch Tests, Monitoring und Parallelbetrieb. Ziel ist eine modernisierbare Architektur, ohne Big-Bang-Rewrite und ohne Logikverlust.

Modernisierungen scheitern in der Praxis selten am Compiler oder an einem Framework, sondern an falschen Annahmen über das Systemverhalten. Über Jahre gewachsene Delphi-Anwendungen enthalten typischerweise Fachregeln in GUI-Events, SQL in Formularlogik, Varianten pro Kunde/Mandant, historisch bedingte Sonderfälle sowie Integrationen, die nur „im Betrieb“ dokumentiert sind.

Ein Big-Bang-Rewrite zwingt dazu, dieses Wissen neu zu rekonstruieren – inklusive der Fehler, die das Altsystem längst nicht mehr macht. Der bessere Ansatz ist, die Fachlogik als Vermögenswert zu behandeln: isolieren, absichern, dann Schritt für Schritt modernisieren.

Ein tragfähiges Zielbild für prozesskritische B2B-Systeme ist nicht „alles neu“, sondern eine Architektur, die Veränderungen ermöglicht – ohne den laufenden Betrieb zu gefährden:

• klare Trennung von UI, Domänenlogik, Datenzugriff und Integrationen
• Test- und Messbarkeit (Regression, Logging, Monitoring, reproduzierbare Builds)
• schrittweise Austauschbarkeit (UI modernisieren ohne sofortige DB-Migration – oder umgekehrt)
• API-Fähigkeit (z. B. REST), um Portale, Mobile oder System-Integrationen anzubinden
• betriebsfähige Deployments mit Rollback-Option

Delphi eignet sich dafür gut, weil bestehende Units und Domänenklassen weiterverwendet werden können, während außen herum modernisiert wird.

Bevor Code angepasst wird, braucht es eine belastbare Entscheidungsgrundlage – keine Voll-Dokumentation. Bewährt haben sich diese drei Ergebnisse:

• Fachlogik-Landkarte: kritische Use-Cases, Regeln/Berechnungen, Varianten (Mandanten/Länder/Kunden), Schnittstellen, Jobs/Batch-Läufe.
• Risikoprofil: besonders fehlerkritische Bereiche, Datenqualität, regulatorische Anforderungen, Engpässe im Betrieb (Performance, Stabilität, Wartbarkeit).
• Modernisierungs-Backlog: priorisierte Pakete nach Business-Wert und Risiko (was muss stabil bleiben, was darf sich ändern, was später).

Damit lässt sich Modernisierung planbar machen: mit klaren Inkrementen statt einem einzigen „Alles-oder-nichts“-Projekt.

Damit Fachlogik nicht „versehentlich“ verändert wird, braucht es eine Absicherung, die unabhängig vom UI-Refactoring funktioniert. Typische Bausteine:

• Characterization/Golden-Master-Tests: vorhandenes Verhalten wird über repräsentative Eingaben/Ausgaben eingefroren (Reports, Berechnungen, Prozessschritte).
• Regressionstests auf Use-Case-Ebene: die geschäftskritischen Abläufe werden automatisiert oder halbautomatisiert nachgestellt.
• Telemetry: Logging, Metriken und Fehlerbilder werden vor/nach einer Änderung vergleichbar gemacht.
• Parallelbetrieb & kontrollierte Umstellung: neue Module laufen neben dem Bestand (Feature Toggles, Pilotgruppen), mit klarer Rollback-Strategie.

Только когда эти защитные сети созданы, имеет смысл собственно техническая модернизация — поскольку риск и доработка резко снижаются.

Наиболее частая причина потери логики — смешение UI, доступа к данным и предметных правил. Поэтому модернизация начинается с разделения слоев — а не с замены UI‑фреймворка.

Прагматичная цель — 3‑слойная структура:

• Presentation: VCL/FMX, Presenter/ViewModel, только валидация, близкая к UI (формат, обязательные поля)
• Business: доменные модели, сервисы, правила, логика состояний, расчёты
• Data/Integration: репозитории, доступ к БД, адаптеры к ERP/DMS/CRM, REST-клиенты, обмен сообщениями

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

При применении Strangulation Pattern новое целенаправленно создаётся «рядом» с существующим: новые функции реализуются в разомкнутой структуре, в то время как старое решение продолжает работать. Шаг за шагом новый слой принимает на себя всё больше ответственности, пока старые части не становятся необходимыми.

Пример (типично для B2B):

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

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

В зависимости от исходной ситуации эти блоки часто имеют значение — решающим является приоритизация по риску и бизнес‑ценности:

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

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

Полная переработка в ряде случаев оправдана — но часто это самый дорогой путь к «современной технике». Эти вопросы помогают оценить ситуацию:

• Полностью ли понятна и тестируема предметная логика — или много знаний скрыто в операционной деятельности?
• Существуют ли жёсткие дедлайны (например, конец поддержки платформы, требования соответствия), исключающие параллельную эксплуатацию?
• Насколько велика вариативность (логика клиентов/мандантов)?
• Насколько критична доступность и какова терпимость к изменениям в процессах?
• Какие части действительно «виноваты» (UI, доступ к данным, интеграции, деплоймент) — а какие стабильны?

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

Delphi-аудит модернизации (для критичных для процессов приложений): мы анализируем архитектуру, зависимости, зоны риска и предоставляем приоритезированную дорожную карту того, как модернизировать, не потеряв предметную логику.

• Входные данные: кодовая база (только для чтения), настройки сборки, 2–3 ключевых сценария использования, окружение системы (БД, интеграции).
• Результат: карта предметной логики/модулей, анализ рисков и зависимостей, рекомендуемая целевая архитектура, план реализации по инкрементам с обеспечением надежности (тесты/параллельная эксплуатация).
• Опционально: Proof of Concept для разъединения + первый Golden-Master-тест.

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

Можно ли модернизировать Delphi, не переписывая приложение?
Да. Во многих случаях сначала отделяют предметную логику от доступа к данным, затем проводят техническую модернизацию. Это снижает риск и поддерживает стабильность эксплуатации.

Как предотвратить, чтобы предметная логика не изменялась «тихо»?
С помощью Golden-Master-/регрессионных тестов, телеметрии и контролируемой параллельной эксплуатации с четкой стратегией отката.

Какие шаги часто приносят самый быстрый эффект?
Прозрачность (оценка), отделение UI от SQL, замена BDE и слой API/сервисов для интеграций — каждый элемент защищён тестами.

Сколько времени занимает модернизация?
Это зависит от критичности сценариев использования, разнообразия вариантов и зависимостей. Аудит обычно в короткие сроки предоставляет надежную дорожную карту и приоритизированные инкременты.