Многие компании годами или десятилетиями эксплуатируют стабильные Delphi-приложения, которые моделируют ядро их процессов: обработка заказов, производство, сервис, логистика, расчёты, управление оборудованием, документооборот. В этих системах содержится не только код, но и надёжное взаимодействие бизнес‑правил, модели данных, пользовательских сценариев и эксплуатационного опыта. Именно это делает модернизацию сложной: реальная ценность редко в интерфейсе, а в наработанной предметной логике.
Если под модернизацией понимать «построить заново», потеря логики запрограммирована заранее. Не потому, что новые технологии по сути плохи, а потому, что имплицитные знания из наследия — особые случаи, исторические данные, исключения в процессах, регуляторные детали — при переносе часто не восстанавливаются полностью. В результате возникают дорогие регрессионные ошибки, изменяются времена процессов, падает приемлемость у пользователей, и проект длится дольше, чем планировалось.
Тем не менее Delphi хорошо поддаются модернизации без утраты предметной логики. Ключ — контролируемый поэтапный подход: сначала создать прозрачность (архитектура, данные, риски), затем разъединить слои (UI, доступ к данным, доменная логика), затем модернизировать (драйверы БД, Unicode/64‑бит, API, сервисы, мультиплатформенность) — при этом обеспечить непрерывную работу системы. В статье описаны практичные паттерны модернизации, типичные подводные камни и пошаговый подход, который работает в B2B‑средах с высокой критичностью процессов.
Почему модернизация Delphi редко бывает «техническим проектом»
В реальности модернизации терпят неудачу не из‑за отсутствия флага компилятора, а из‑за неверных предположений о поведении системы. Delphi‑приложения, которые расширялись годами, часто содержат:
- Бизнес‑правила в GUI‑событиях (OnClick, OnExit, OnValidate), часто распределённые по множеству форм
- SQL‑запросы «приближённо к поверхности», оптимизированные годами под одну конкретную базу данных
- Обходные пути для исторических данных, особых случаев, вариантов для клиентов или логики мульти‑тенантности
- Batch‑процессы, которые на практике запускаются в фиксированное время и имеют зависимости
- Интеграции с ERP, DMS, CRM или оборудованием, которые слабо документированы
- Молчащее знание в виде эксплуатационных процедур: «Если ошибка X, то сначала проверить Y»
Тот, кто начинает с Big‑Bang‑переписывания, вынужден воспроизводить всё это знание заново — вместе с ошибками, которых давно нет в старом решении. Лучший подход — рассматривать предметную логику как актив: сначала изолировать, затем защитить, затем модернизировать.
Модернизация без потери логики: целевая картина и руководящие принципы
Устойчивое целевое состояние для B2B‑систем — это не «всё новое», а архитектура, которая позволяет изменения. Типичные свойства:
- Разделение ответственности (UI, домен/бизнес‑логика, доступ к данным, интеграции)
- Тестируемость и измеримость (регрессионные тесты, логирование, мониторинг, воспроизводимые сборки)
- Пошаговая заменяемость (обновлять UI, не перестраивая сразу модель данных; мигрировать БД, не переписывая UI)
- API‑возможности (REST‑Server или слой сервисов для подключения порталов, мобильных клиентов и интеграций)
- Оперируемость (Windows‑ и Linux‑Services, понятные процессы деплоя, стратегия отката)
В Delphi это особенно достижимо, потому что вы можете продолжать использовать существующие Units и доменные классы, модернизируя оболочку: доступ к данным от BDE к BDE‑Ablösung с нативной привязкой, новые REST‑эндпоинты, новые UI‑модули, новые deploy‑процессы.
Инвентаризация: что действительно нужно сохранить?
Прежде чем «трогать» код, имеет смысл провести структурированную инвентаризацию. Цель — не полная документация, а надёжная база для принятия решений.
1) Карта предметной логики вместо марафона чтения кода
Практически зарекомендовала себя карта предметной логики с такими перспективами:
- Use‑cases: Какие ключевые процессы критичны для бизнеса? (например, создание заказа, счёт‑фактура, сторно, возврат, сервисное обслуживание оборудования, договор техобслуживания)
- Правила: Какие валидации, вычисления, автоматы состояний существуют?
- Варианты: Тенанты, конфигурации клиентов, национально‑специфические правила
- Интерфейсы: Импорт/экспорт, ERP/DMS/CRM, устройства/протоколы
- Batch/Jobs: ночные прогонки, отчёты, согласования данных
Из такой карты формируются приоритетные пакеты модернизации: что должно оставаться стабильным, что может измениться, что можно отложить.
2) Сделать технический долг видимым
Типичные технические долги в старых Delphi‑системах:
- Зависимости от Borland BDE/Paradox
- ANSI‑строки/отсутствие миграции на Unicode
- Только 32‑бит, устаревшие сторонние компоненты
- Монолитная логика форм, глобальные переменные, юниты с побочными эффектами
- Неясные границы транзакций и «SQL повсюду»
Искусство в том, чтобы не стремиться догматично «очистить» всё, а упорядочить эти пункты таким образом, чтобы минимизировать риск и максимизировать бизнес‑ценность.
Архитектурная развязка: рычаг против потери логики
Самая частая причина потери логики — смешение UI, доступа к данным и бизнес‑правил. Поэтому модернизация начинается с развязки — а не с «нового UI‑фреймворка».
Layer-3 архитектура как прагматичное целевое состояние
Для многих наследных Delphi‑приложений хорошо работает Layer-3 архитектура:
- 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‑замена и планирование FireDAC
Центральный шаг в модернизации — замена BDE. Компании часто недооценивают, что дело не только в драйверах, но и в семантике SQL, транзакциях, блокировках, типах данных и поведении при ошибках. Современные Delphi‑стэки обычно ставят в основу BDE-Ablosung mit nativer Anbindung с нативными драйверами (например, для MariaDB/MySQL, PostgreSQL, SQL Server).
Что действительно решается при переходе
- Целевая СУБД: остаётся ли текущая БД? Имеет ли смысл миграция БД (например, из Paradox/Firebird в MariaDB или PostgreSQL)?
- Модель транзакций: где начинаются/заканчиваются транзакции? Какие use‑cases должны быть атомарными?
- Согласованность/блокировки: оптимистическая vs. пессимистическая, обработка deadlock, стратегии повторов
- 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 должен по возможности опираться напрямую на доменные сервисы. Типичные компоненты:
- Аутентификация/авторизация (роли, тенанты, права)
- DTO/сериализация с понятной стратегией версионирования
- Концепция транзакций и ошибок (HTTP‑статусы, Problem‑Details, логирование)
- Идемпотентность и параллелизм (для повторов, обработки очередей)
Так REST‑Server становится стабильной точкой интеграции — а не «вторым клиентом».
Модернизация Linux‑Services и Windows‑сервисов
Batch‑процессы и интеграции во многих компаниях работают как Windows‑сервисы, задания Task Scheduler или даже как «скрытые» десктоп‑инстансы. При модернизации стоит консолидировать:
- Отделение UI от фоновой логики
- Конфигурируемые графики запусков и понятные эксплуатационные параметры
- Аккуратное логирование (структурированные логи, корреляция по задаче/запросу)
- Возможность запуска сервисов под Linux (например, для контейнеризированного деплоя)
Преимущество не только «модное», но и операционное: воспроизводимая эксплуатация, меньше ручных вмешательств, лучшая отладка.
Модернизация UI без вмешательства в ядро: VCL, FMX и гибридные подходы
Многие планы модернизации стартуют с UI. Это может быть оправдано — если ясно, какую ценность это даёт. При развязанной бизнес‑логике UI можно обновлять с существенно меньшим риском.
Пошаговая модернизация VCL‑приложений
VCL остаётся в многих B2B‑сценариях надёжным выбором, особенно в окружениях с сильной Windows‑ориентацией и высокой производительностью работы на десктопе. Модернизация может означать:
- Сокращение логики в UI (Presenter/ViewModel), перенос бизнес‑правил в сервисы
- Упорядочение набора компонентов, консолидация собственных контролов
- Улучшение отзывчивости (Async, фоновые задачи, прогресс, отмена)
- Доступность интерфейса, согласованная валидация, улучшенные сообщения об ошибках
Это даёт ощутимый эффект, не переписывая весь интерфейс целиком.
Delphi мультиплатформенность: когда имеет смысл FMX
Если есть реальные мультиплатформенные требования (Windows, macOS, возможно Linux в контексте сервисов), FMX может быть опцией. Решающее — ожидания: мультиплатформенность добавляет тестирования и интеграции (шрифты, печать, диалоги ОС, файловая система, упаковка/деплой). Затраты предсказуемы, если предметная логика уже находится в чистом слое.
Частый прагматичный путь — гибридный: VCL остаётся для Windows‑клиента, а новые фронтенды (портал, мобильное приложение) подключаются через REST‑Server. Так мультиплатформенность достигается через границы системы, а не одним UI‑стэком.
Тестирование и регрессии: как «закрепить» предметную логику
«Потеря предметной логики» на практике означает: система в краевых случаях даёт другие результаты. Это редко сразу заметно, но дорого обходится. Поэтому тестируемость — не роскошь, а инструмент модернизации.
Золотые use‑cases и опорные данные
Эффективно иметь набор «золотых» use‑cases: реальные критические сценарии с определённой данными и ожидаемым результатом (например, цепочка документов от предложения до кредит‑ноты, или наряд‑заказ на обслуживание с запасными частями и учётом рабочего времени). Они используются как регрессионные тесты или как повторяемые тест‑скрипты.
Важно: проверять не только успешные пути, но и типичные ошибочные сценарии (конфликты блокировок, отсутствие прав, неполные справочники, дублирующийся файл импорта).
Автоматизация там, где она даёт максимальный эффект
Не каждый наследный проект нуждается сразу в 80% покрытии unit‑тестами. Высокий ROI часто достигается в областях:
- Доменные сервисы (вычисления, правила, переходы состояний)
- Доступ к данным с чёткими контрактами (маппинг, SQL, транзакции)
- API‑тесты (аутентификация, права, версионирование)
Цель — стабильность при изменениях, а не академические метрики.
Практическая модель работ: дорожная карта модернизации по этапам
С точки зрения B2B модернизация должна оставаться поставляемой. Типичная дорожная карта, ориентированная на риски:
Этап 1: Анализ, целевая архитектура, Quick Wins (2–6 недель)
- Карта системы (модули, БД, интерфейсы, задания, зависимости)
- Матрица рисков (BDE, сторонние поставщики, 32/64‑бит, Unicode, деплой)
- Определение целевой архитектуры (Layer-3, слой сервисов, API‑стратегия)
- Quick Wins: стабилизировать процесс сборки, улучшить логирование, навести порядок в версии‑контроле
Этап 2: Развязка предметной логики (непрерывно, инкрементально)
- Идентифицировать доменные сервисы и вынести их из форм
- Ввести фасады‑репозитории
- Первые регрессионные тесты для критических use‑cases
Этап 3: Модернизация доступа к данным/DB‑слоя
- Внедрить FireDAC, установить концепт соединений и транзакций
- Модульная BDE‑замена (или миграция БД с параллельной эксплуатацией)
- Тестирование производительности и поведения блокировок под нагрузкой
Этап 4: Доработка REST‑Server и интеграций
- API с аутентификацией, правами, версионированием
- Подключение порталов/интеграций без дублирования логики
- Консолидация сервисов для batch и фоновых процессов
Этап 5: Платформа и решения по UI (64‑бит, ARM64, мультиплатформенность)
- 64‑битная сборка, замена зависимостей
- Проверка/планирование совместимости с ARM64
- Модернизация UI: обновление VCL или FMX/гибрид в зависимости от бизнес‑выгод
Порядок выбран так, чтобы вы рано получили прозрачность, затем стабилизировали ядро и только потом масштабировали «видимые» изменения. Это снижает риск и сохраняет предсказуемость эксплуатации.
Типичные анти‑паттерны: что удорожает модернизацию
Некоторые шаблоны постоянно встречаются в аудитах и спасательных проектах:
- «Мы переписываем заново и берём только фичи»: почти всегда приводит к потере логики, потому что пропадают особые случаи.
- API как параллельный мир: бизнес‑правила остаются в клиенте, а в бэкенде изобретаются заново.
- Смена БД без семантических тестов: те же данные, но иное поведение (NULL, сортировка, логика дат).
- Позднее управление зависимостями: 64‑бит/ARM64 терпит неудачу из‑за маленькой DLL прямо перед запуском.
- «Рефакторинг сначала» без целевой картины: много изменений, мало измеримой пользы, большие регрессии.
Контрпример всегда одинаков: сначала прояснить целевую архитектуру и риски, затем инкрементально перестраивать, тестируя и визуализируя предметную логику.
Вывод: модернизировать — значит сохранять и целенаправленно развивать
Модернизация Delphi без потери предметной логики — это не противоречие, а дисциплина. Компаниям не нужно выбирать между «полностью оставить» и «полностью заменить». При чистом разделении архитектуры (например, Layer-3), контролируемой BDE‑замене в сторону FireDAC, API‑стратегии через REST‑Server и ясном плане по Unicode, 64‑бит и новым платформам вроде Windows 11 ARM64 можно поэтапно перевести выросшую систему в устойчивую архитектуру.
Ключевой момент — рассматривать предметную логику как основной актив: изолировать, сделать тестируемой, затем модернизировать. Так формируется архитектура, которая поддерживает порталы, сервисы и мультиплатформенные требования, не рискуя текущей эксплуатацией.
Если вы планируете Delphi модернизацию и хотите аккуратно объединить предметную логику, доступ к данным и эксплуатацию, обсудите с нами реалистичный путь миграции: https://net-base-software-gmbh.de/kontakt/