Birçok şirket yıllardır veya on yıllardır çekirdek süreçlerini yansıtan stabil Delphi uygulamalarını işletiyor: sipariş yönetimi, üretim, servis, lojistik, faturalama, cihaz yönetimi, belge iş akışları. Bu sistemlerde yalnızca kod değil; iş kuralları, veri modeli, kullanıcı akışı ve işletme tecrübesinden oluşan sağlam bir etkileşim vardır. Tam da bu durum modernizasyonu zorlaştırır: asıl değer nadiren arayüzde, çoğunlukla olgunlaşmış iş mantığındadır.
Modernizasyon „yeniden yapmak“ olarak algılanırsa, kayıp kaçınılmazdır. Bunun nedeni yeni teknolojilerin başlı başına kötü olması değil; eski sistemde yerleşik olan örtük bilginin — özel durumlar, tarihî veriler, süreç istisnaları, düzenleyici ayrıntılar — taşınma sırasında sıklıkla tam olarak yeniden oluşturulamamasıdır. Sonuç pahalı regresyon hataları, değişen süreç süreleri, kabul sorunları ve planlanandan uzun süren projelerdir.
Delphi ise iş mantığını kaybetmeden çok iyi modernize edilebilir. Anahtar kontrollü, adım adım bir yaklaşımdır: önce şeffaflık sağlamak (mimari, veriler, riskler), sonra ayrıştırmak (UI, veri erişimi, domain mantığı), ardından modernize etmek (veritabanı sürücüleri, Unicode/64-Bit, API’ler, servisler, çoklu platform) — ve tüm bunlar yapılırken işletmenin devamlılığını güvence altına almak. Bu yazı, pratikte uygulanabilir modernizasyon desenlerini, tipik tuzakları ve yüksek işlem kritikliği olan B2B ortamlarında işe yarayan bir yaklaşımı tanımlamaktadır.
Neden Delphi modernizasyonu nadiren yalnızca bir „teknik proje“dir
Gerçekte modernizasyonlar eksik bir compiler-flag nedeniyle değil, sistem davranışı hakkında yanlış varsayımlar yüzünden başarısız olur. Yıllar içinde genişletilmiş Delphi uygulamaları sıklıkla şunları içerir:
- GUI olaylarında (OnClick, OnExit, OnValidate) yer alan iş kuralları, genellikle birçok forma yayılmış
- Yüzeye „yakın“ SQL ifadeleri ve yıllardır tam olarak tek bir veritabanı için optimize edilmiş sorgular
- Tarihî veriler, özel durumlar, müşteri varyantları veya çoklu kiracı (mandant) mantığı için devre dışı bırakmalar
- Sabit zamanlarda çalışan ve bağımlılıkları olan batch süreçleri
- ERP, DMS, CRM veya makinelerle entegrasyonlar; çoğu zaman zayıf dokümante edilmiş
- „Eğer hata X ise önce Y’yi kontrol et“ gibi işletme rutinleri şeklinde sessiz bilgi
Buraya Big-Bang yeniden yazımıyla girenler, tüm bu bilgiyi yeniden üretmek zorunda kalır — eskiden artık meydana gelmeyen hatalar dahil. Daha iyi yaklaşım, iş mantığını bir varlık olarak ele almaktır: önce izole etmek, sonra güvence almak, sonra modernize etmek.
Logik kaybı olmadan modernizasyon: Hedef görüntü ve temel ilkeler
B2B sistemleri için sürdürülebilir bir hedef görüntü „her şeyi yenilemek“ değil, değişikliklere izin veren bir mimaridir. Tipik özellikler:
- Ayırılmış sorumluluklar (UI, domain/iş mantığı, veri erişimi, entegrasyonlar)
- Test edilebilirlik ve ölçülebilirlik (regresyon testleri, logging, monitoring, tekrar üretilebilir buildler)
- Aşamalı değiştirilebilirlik (UI’yi modernize etmek için veri modelini hemen yeniden inşa etmek zorunda olmamak; DB’yi taşırken UI’yi yeniden yazmamak)
- API yeteneği (REST-Server veya bir servis katmanı, portallar, mobil ve entegrasyonların bağlanması için)
- İşletilebilirlik (Windows- ve Linux-Services, belirgin deploy prosedürleri, rollback stratejisi)
Delphi için bu özellikle ulaşılabilir çünkü mevcut unit’ler ve domain sınıfları dışarıdan modernize ederken yeniden kullanılabilir: veri erişimini BDE’den BDE-Ablösung mit nativer Anbindung’a taşımak, yeni REST endpoint’leri, yeni UI modülleri, yeni deployment’lar eklemek mümkündür.
Envanter: Gerçekten ne korunmalı?
Kod „elle alınmadan“ önce yapılandırılmış bir envanter yapmak faydalıdır. Amaç tam belge değil, güvenilir bir karar altyapısı oluşturmaktır.
1) Kod okuma maratonu yerine iş mantığı haritası
Pratikte işe yarayan iş mantığı haritası şu perspektifleri içerir:
- Use-Case’ler: Hangi çekirdek akışlar iş açısından kritik? (ör. sipariş oluşturma, fatura, iptal, iade, makine servisi, bakım sözleşmesi)
- Kurallar: Hangi doğrulamalar, hesaplamalar, durum makineleri mevcut?
- Varyantlar: Mandantlar, müşteri konfigürasyonları, ülkeye özgü kurallar
- Schnittstellen: İçe/Dışa aktarma, ERP/DMS/CRM, cihazlar/protokoller
- Batch/Jobs: gece çalışan işler, raporlar, veri senkronizasyonları
Bu haritadan önceliklendirilen modernizasyon paketleri çıkar: Hangisi stabil kalmalı, hangisi değişebilir, hangisi sonra ele alınabilir.
2) Teknik borcu görünür kılmak
Eski Delphi sistemlerinde tipik teknik borçlar:
- Borland BDE/Paradox bağımlılıkları
- ANSI stringler/eksik Unicode göçü
- 32-Bit-Only, eskimiş üçüncü taraf bileşenler
- Monolitik form mantığı, global değişkenler, yan etki ağırlıklı unit’ler
- Belirsiz işlem (transaction) sınırları ve „her yerde SQL“
Sanat şu: bu maddeleri dogmatik biçimde temizlemek değil; riski minimuma indirirken iş değeri maksimize edecek bir sıraya koymaktır.
Mimari ayrıştırma: Mantık kaybına karşı kaldıraç
Logik kaybının en sık nedeni UI, veri erişimi ve iş kurallarının karışmasıdır. Modernizasyon bu yüzden ayrıştırmayla başlar — „yeni UI framework“ ile değil.
Layer-3 mimarisi pratik bir hedef durum olarak
Birçok Delphi legacy uygulaması için Layer-3 Architektur çok iyi çalışır:
- Presentation Layer: VCL/FMX formları, ViewModel/Presenter’lar, doğrulama yalnızca UI yakınında (format, zorunlu alanlar)
- Business Layer: Domain modeller, servisler, kurallar, durum mantığı, hesaplamalar
- Data/Integration Layer: Repository’ler, SQL/ORM parçaları, arayüz adaptörleri, REST-client’lar, messaging
Bu yapının getirisi: iş mantığı test edilebilir ve yeniden kullanılabilir hale gelir. Sonrasında bir Kundenportal, bir REST-Server veya bir Linux servisi aynı domain servislerini kullanabilir. Böylece dış katmanı modernize ederken çekirdek mantığı yeniden icat etmezsiniz.
Strangulation Pattern: Eski sistemi adım adım „sarmak“
Yaygın bir geçiş deseni Strangulation Pattern’dır: Yeni fonksiyonlar zaten yeni yapıda (ör. domain servis + repository) oluşturulur, aynı zamanda mevcut formlar kademeli olarak dönüştürülür. Eski dünya çalışır halde kalır, ama parça parça yeni olanla değiştirilir.
Burada önemli olan bağımlılıkları tersine çevirmektir: „Form SQL çağırmasın“, yerine „Form servis çağırsın“ ve servisin karar vermesidir. Bu küçük tersine çevirme genellikle en büyük kazançtır.
Veri erişimini modernize etmek: BDE-Ablösung ve FireDAC planlamak
Modernizasyonun merkezi adımlarından biri BDE-Ablösung’dır. Şirketler burada sıklıkla sadece sürücülerle işin bittiğini sanır; oysa mesele SQL semantiği, transaction’lar, locking, veri tipleri ve hata davranışıdır. Modern Delphi yığınları tipik olarak yerel sürücülerle BDE-Ablosung mit nativer Anbindung’e dayanır (ör. MariaDB/MySQL, PostgreSQL, SQL Server için).
Geçişte gerçekten karar verilmesi gerekenler
- Hedef veritabanı: Mevcut DB mi kalacak? Paradox/Firebird’den MariaDB veya PostgreSQL’e geçiş gibi bir yeniden yapılandırma mantıklı mı?
- Transaction modeli: Transactionlar nerede başlayıp bitmeli? Hangi use-case’lerin atomik olması gerekiyor?
- Concurrency/Locking: Optimistik vs. pesimist, deadlock yönetimi, retry stratejileri
- SQL dialekti: Tarih fonksiyonları, string davranışı, NULL yönetimi, case-sensitivity
- Performans: Indeksler, sorgu planları, paging, toplu insert’ler
İş mantığı verinin davranışına sıkı bağlıdır. Veriyi „yanı başında“ geçirirken risk alırsanız pratikte ince sapmalar ortaya çıkar: yuvarlamalar, sıralama farkları, tarih sınırları, kilit çatışmaları. Bu yüzden veri katmanı modernizasyon planına erken dahil edilmelidir; geçiş yolu ve test veri stratejisiyle birlikte.
FireDAC-Migration için pragmatik adımlar
Uygulamayı tek seferde yeniden inşa etmek yerine aşağıdaki sıra işe yarar:
- Bir veri erişim katmanı (Repository/DAO) fasadı olarak devreye almak
- Belli use-case’leri önce FireDAC ile çalışacak şekilde geçirmek (ör. önce „okuma“, sonra „yazma“)
- Connection-handling, hata yönetimi, logging’i standartlaştırmak
- Fasat stabil hale geldikçe BDE bileşenlerini kademeli olarak kapatmak
Böylece uygulama her an teslim edilebilir kalır ve „her şey yarım“ durumda uzun süre beklemez.
Unicode, 64-Bit ve bağımlılıklar: Modernizasyon tuzakları detayları
Çok sayıda modernizasyon kavramda başarısız olmaz, ama hafife alınan detay konularında çöker. Bu üç konu Delphi projelerinde özellikle yaygındır.
Unicode göçü: Sadece stringler değil, veri akışları
Çok eski Delphi sürümlerinde sistemler ANSI dünyasından gelir. Unicode göçü şu alanları etkiler:
- String tipleri ve dönüşümleri (WideString/AnsiString/UnicodeString)
- Dosya ve yol yönetimi (Windows-API, ağ yolları)
- İçe/Dışa aktarma (CSV, sabit alan uzunlukları, EDI, legacy arayüzler)
- Veritabanında sıralama/kollasyon
Önemli olan kritik veri akışlarını belirlemek (ör. fatura metinleri, ürün adları, uluslararası adresler) ve bunlar için regresyon testleri kurmaktır. Unicode bir „yeniden yapı“ değil, uçtan uca bir kalite sürecidir.
64-Bit geçişi: Sadece bellek değil
64-Bit’e geçiş genellikle „pointer boyutları“ ile sınırlı zannedilir. Gerçekte daha çok şunlardır:
- 64-Bit desteği olmayan eski üçüncü taraf bileşenler
- COM/ActiveX bağımlılıkları
- DLL’ler ve sürücüler (barkod, cihazlar, kriptografi, imza)
- Installer/deploy ve Registry yolları (WOW64)
Akıllıca bir strateji önce tüm dış bağımlılıkların envanterini çıkarmak ve alternatifleri tanımlamaktır. Bu sayede 64-Bit adımı planlanabilir olur ve sürpriz bir paket haline gelmez.
Windows 11 ARM64: Geç ödemek yerine erken kontrol
Windows 11 ARM64 ile yeni bir hedef sistem sınıfı ortaya çıkıyor. Her şirketin hemen native ARM64 build’lere ihtiyacı olmasa da, erken değerlendirme akıllıca olur:
- ARM64 altında çalışmayan native bağımlılıklar (DLL’ler, sürücüler) var mı?
- Uygulama emülasyon üzerine mi bağlı, ve bu kabul edilebilir mi?
- Installer nasıl davranır, güncelleme/onarma süreci nasıl işler?
Modernizasyon projelerinde bu tip konular genellikle „geç“ ele alınır ve pahalı olur. Daha iyi yol: platform yol haritasına erken dahil etmek ve teknik olarak doğrulamak.
REST-Server ve servisler: İş mantığını portal ve entegrasyon için kullanılabilir kılmak
Birçok şirket Delphi’i masaüstü uygulaması „eski görünüyor“ diye değil, yeni gereksinimler ortaya çıktığı için modernize eder: müşteri portalı, partner erişimleri, mobil süreçler, ERP/DMS/CRM ile entegrasyon, raporlama hattı. Bunun için net arayüzler gerekir. Bir REST-Server genellikle pratik bir köprüdür.
Önce API mi? Ancak haklar ve domain mantığı birlikte gelirse
Bir API ancak istemci ile aynı iş mantığını uygularsa kazançtır. Aksi halde iki farklı kural kümesi ortaya çıkar: masaüstünde bir tanesi, backend’de diğeri. Sonuç tutarsızlıklar ve güvenlik açıklarıdır.
Bu yüzden REST-Server katmanı mümkün olduğunca doğrudan domain servisleri üzerine kurulmalıdır. Tipik yapı taşları:
- Kimlik doğrulama/Yetkilendirme (roller, mandantlar, haklar)
- DTO’lar/serileştirme ile net versiyonlama kuralları
- Transaction ve hata konsepti (HTTP durum kodları, Problem-Details, logging)
- Idempotenz ve eşzamanlılık (retry’ler, kuyruk işleme için)
Böylece REST-Server stabil bir entegrasyon noktası olur — „ikinci bir istemci“ değil.
Linux-Services ve Windows servislerini modernize etmek
Birçok işletmede batch süreçleri ve entegrasyonlar Windows servisleri, Task Scheduler işleri veya hatta „gizli“ masaüstü örnekleri olarak çalışır. Modernizasyon esnasında konsolidasyon faydalıdır:
- UI ile arka plan mantığını ayırmak
- Yapılandırılabilir çalıştırma zamanları ve net işletme parametreleri
- Temiz logging (yapılandırılmış loglar, job/request başına korelasyon)
- Servisleri Linux altında çalıştırma seçeneği (ör. container’lı deployment’lar için)
Avantaj sadece „modern“ olmak değil, operasyoneldir: tekrar üretilebilir işletim, daha az manuel müdahale, daha iyi hata analizi.
UI’yi çekirdeğe dokunmadan modernize etmek: VCL, FMX ve hibrit yaklaşımlar
Birçok modernizasyon planı UI’den başlar. Bu anlamlı olabilir — yeter ki ne kazanılacağı net olsun. İş mantığı ayrılmışsa UI’yi yenilemek çok daha az risklidir.
VCL uygulamalarını kademeli modernize etmek
VCL birçok B2B senaryosunda hâlâ sağlam bir tercih, özellikle Windows-ağırlıklı ve masaüstünde yüksek üretkenlik gerektiren ortamlarda. Modernizasyon şunları kapsayabilir:
- UI mantığını azaltmak (Presenter/ViewModel), iş kurallarını servislerde toplamak
- Komponent koleksiyonunu sadeleştirmek, kendi kontrolleri konsolide etmek
- Duyarlılığı artırmak (Async, arka plan işler, ilerleme, iptal)
- Erişilebilir kullanım, tutarlı doğrulama, daha iyi hata mesajları
Bu, tüm arayüzü yeniden yazmadan hissedilir fayda sağlar.
Delphi çoklu platform: FMX ne zaman anlamlıdır
Gerçek çoklu platform gereksinimleri varsa (Windows, macOS, gerekirse Linux servis bağlamında), FMX bir seçenek olabilir. Belirleyici olan beklentidir: Çoklu platform ek test ve entegrasyon işidir (fontlar, yazdırma, OS dialogları, dosya sistemi, paketleme/deploy). İş mantığı temiz bir katmanda zaten bulunuyorsa maliyetler iyi hesaplanabilir.
Pragmatik bir yol genelde hibrittir: VCL Windows istemci için kalır, yeni frontend’ler (portal, mobil uygulama) REST-Server üzerinden beslenir. Böylece çoklu platform sistem sınırları üzerinden sağlanır, tek bir UI yığını üzerinden değil.
Test ve regresyon: İş mantığını „çivilemek“ nasıl yapılır
„İş mantığını kaybetmek“ pratikte şunu ifade eder: Sistem kenar durumlarda farklı sonuçlar üretir. Bu genellikle hemen görünmez, ama pahalıdır. Bu yüzden test edilebilirlik lüks değil, modernizasyonun bir aracıdır.
Altın Use-Case’ler ve referans veriler
Gerçek, kritik akışları tanımlayan „altın“ use-case setleri faydalıdır: belirlenmiş veri durumuna ve beklenen sonuçlara sahip işler (ör. tekliften mahsup/avans dâhil belge zinciri veya yedek parçalar ve zaman kayıtları içeren bakım emri). Bunlar regresyon testleri veya en azından tekrarlanabilir test senaryoları olarak kurulmalıdır.
Önemli: sadece başarılı yollar değil, tipik hata yolları da (kilit çatışmaları, yetki eksikliği, eksik temel veriler, çift import dosyası) dahil edilmelidir.
En büyük kaldıraçta otomasyon
Her legacy proje hemen %80 unit-test kapsamı gerektirmez. Yüksek ROI çoğunlukla şunlarda görülür:
- Domain servisleri (hesaplamalar, kurallar, durum değişiklikleri)
- Net contract’ları olan veri erişimi (mapping, SQL, transactionlar)
- API testleri (Auth, haklar, versiyonlama)
Hedef değişikliklerde istikrar sağlamak, akademik metrikler değil.
Pratik yol haritası: Aşamalı bir modernizasyon planı
B2B perspektifinden modernizasyonun teslim edilebilir kalması gerekir. Risklere odaklanan tipik bir yol haritası:
Aşama 1: Analiz, hedef mimari, Quick Wins (2–6 Wochen)
- Sistem haritası (modüller, veritabanları, arayüzler, işler, bağımlılıklar)
- Risk matrisi (BDE, üçüncü taraflar, 32/64-Bit, Unicode, deploy)
- Hedef mimarinin tanımı (Layer-3, servis katmanı, API stratejisi)
- Quick Wins: build sürecini stabilize etmek, logging’i iyileştirmek, versiyon yönetimini düzene koymak
Aşama 2: İş mantığının ayrıştırılması (sürekli, artımlı)
- Domain servislerini tanımlamak ve formlardan ayırmak
- Repository fasadları uygulamak
- Kritik use-case’ler için ilk regresyon testlerini oluşturmak
Aşama 3: Veri erişimi/DB katmanını modernize etmek
- FireDAC devreye almak, bağlantı ve transaction konsepti oluşturmak
- BDE-Ablösung modül bazında (veya paralel işletimle veritabanı migrasyonu)
- Yük altında performans ve kilit davranışını test etmek
Aşama 4: REST-Server ve entegrasyonları tamamlamak
- Auth, haklar, versiyonlama ile API
- Portallar/entegrasyonları bağlamak, çift mantık üretmeden
- Batch ve arka plan süreçleri için servisleri konsolide etmek
Aşama 5: Platform ve UI kararları (64-Bit, ARM64, Multiplatform)
- 64-Bit build, bağımlılıkların değiştirilmesi
- ARM64 uyumluluğunu incelemek/planlamak
- UI modernizasyonu: VCL yenileme veya FMX/hibrit, iş değeri esas alınarak
Sıra kasıtlı olarak böyle seçilmiştir: önce şeffaflık kazanılır, sonra çekirdek stabil hale getirilir ve ancak ardından „görsel“ değişiklikler geniş ölçekte uygulanır. Bu şekilde risk düşer ve işletme planlanabilir kalır.
Tipik anti-patternler: Modernizasyonu gereksiz pahalı yapanlar
Audit’lerde ve kurtarma projelerinde tekrar eden bazı kalıplar vardır:
- „Yeniden inşa ediyoruz ve sadece özellikleri alıyoruz“: özel durumların eksik kalmasına yol açar ve genelde iş mantığı kaybına götürür.
- API ikinci bir dünya gibi: İş kuralları istemcide bırakılır, backend’de yeniden icat edilir.
- Semantik testler olmadan veritabanı değişikliği: Aynı veriler farklı davranır (NULL, sıralama, tarih mantığı).
- Bağımlılık yönetimi çok geç: 64-Bit/ARM64 küçük bir DLL yüzünden Go-Live öncesinde başarısız olur.
- Hedef görüntü olmadan önce refactoring: çok sayıda değişiklik, ölçülebilir az fayda, yüksek regresyon riski.
Bunun karşı önerisi hep aynıdır: önce hedef mimari ve riskleri netleştirin, sonra artımlı olarak yeniden inşa edin, bu arada iş mantığını test edin ve görünür kılın.
Sonuç: Modernize etmek korumak demektir — ve hedefli olarak genişletmek
Delphi’i iş mantığını kaybetmeden modernize etmek bir çelişki değil, bir disiplindir. Şirketlerin „her şeyi korumak“ ile „her şeyi değiştirmek“ arasında seçim yapmasına gerek yok. Temiz mimari ayrımı (ör. Layer-3), kontrollü bir BDE-Ablösung ile FireDAC’e geçiş, REST-Server üzerinden bir API stratejisi ve Unicode, 64-Bit ve Windows 11 ARM64 gibi yeni platformlar için net bir plan ile olgunlaşmış bir sistem adım adım geleceğe yönelik bir yapıya dönüştürülebilir.
Önemli olan iş mantığını temel bir varlık olarak ele almaktır: izole etmek, test edilebilir yapmak, sonra modernize etmek. Böylece portallar, servisler ve çoklu platform gereksinimlerini destekleyen bir mimari oluşur; işletme riske atılmadan.
Eğer bir Delphi Modernisierung planlıyorsanız ve iş mantığı, veri erişimi ile işletmeyi temiz şekilde birleştirmek istiyorsanız, gerçekçi bir geçiş yolu için bizimle konuşun: https://net-base-software-gmbh.de/kontakt/