Technologický profil
Přehled naší technické základny
Delphi. C#. SQL. APIs.
Technologie, které odpovídají doménové logice, datům a provozu.
Technologie nepoužíváme podle módy, ale podle provozní reality, životnosti, potřeby integrace a schopnosti týmu. Rozhodující není módní výraz, ale zda bude systém později čistě provozovatelný, rozšiřitelný a převzatelný.
Silné pro obchodní logiku a multiplatformní klienty
Delphi je tam silné, kde má vzniklá doménová logika, databázově blízké procesy, reporty a stabilní klienti pro Windows, macOS und Linux být dlouhodobě udržovány.
Zobrazit Delphi
C#
Silné pro REST, služby a portály
C# nasazujeme, když mají portály, moderní backendové služby, REST-API a integrace čistě navázat na stávající podnikové systémy.
Zobrazit C#
Architektura
Layer-3 místo monolitického dědictví
Rozdělujeme vědomě rozhraní, doménovou logiku a přístup k datům, aby byly změny plánovatelné a nové služby se nemusely budovat proti existujícímu systému.
Zobrazit Layer-3
Platformy
Windows 11 ARM64 rovnou zohlednit
Kromě klasických cílů x64 bereme včas v úvahu aktuální platformy jako Windows 11 ARM64, aby nová hardware a nasazení později nebyly mimořádným projektem.
Zobrazit ARM64
Kdy je která cesta smysluplná
Delphi je vhodné, když
- stávající doménová logika má být zachována,
- komplexní desktopové procesy musí zůstat stabilní,
- Windows-, macOS- a Linux-klienti mají vzniknout na společné doménové bázi.
C# je vhodné, když
- se budují REST-servery a služby,
- API a externí integrace jsou v centru pozornosti,
- jsou požadovány moderní servisní architektury.
Hybrid je vhodný, když
- stávající aplikace a nové portály musí spolupracovat,
- desktop, služby a web sdílejí stejnou datovou základnu,
- modernizace má probíhat krokově a jako Layer-3-struktura.
Delphi-modernizace v praxi
Když je stará Delphi-aplikace doménově stále hodnotná, neprovádíme modernizaci naslepo. Nejprve analyzujeme, jak systém skutečně funguje, které procesy nese, kde se přerušují toky dat a které historické zátěže zpomalují provoz. Z toho vznikne modernizační plán, který není hezký jen na papíře, ale v praxi vydrží.
V mnoha narostlých aplikacích není skutečná hodnota v uživatelském rozhraní, ale v letech doménové logiky, speciálních pravidel, výjimek a know‑how. Tuto substanci nelze lehkovážně zahodit. Pečlivě oddělíme odpovědnosti, přeorganizujeme databázi, nahradíme staré přístupové cesty, vytvoříme nová REST-rozhraní a případně doplníme klienty pro Windows, macOS und Linux na téže doménové bázi. Nevznikne tak tvrdý zlom, ale průkazný vývoj s jasným technickým vymezením.
Často to také znamená vrátit historicky vzniklé monolity do podoby, která je udržovatelná, testovatelná a rozšiřitelná. Přístup k datům se stabilizuje, doménová logika se vyjme z kódu rozhraní, rozhraní se stanou plánovatelnými a budoucí rozšíření už nebudou muset bojovat proti existujícímu systému. Cílem není kosmetická modernizace, ale systém, který firmě znovu uvolní prostor pro nové požadavky.
Služby a servery jako součást téže architektury
Mnoho podnikových systémů dnes potřebuje nejen klienta, ale i pozadí služby, Windows- nebo Linux-servisy a REST-servery. Proto tyto části neplánujeme jako pozdější přístavbu, ale jako součást téže architektury. Služba, která je přidána až dodatečně, se téměř vždy stane okrajovým případem.
Pokud mají být data distribuovaně zpracovávána, poskytována rozhraní, prováděny exporty, sledovány importy nebo úlohy spouštěny časově řízeně na pozadí, musí být technická odpovědnost vyjasněna od počátku. Které části běží v klientu, které ve službě, které na serveru, jak se chybovost zviditelní, jak budou sledovatelné změny stavů, jak zůstane doménová logika konzistentní? Na tyto otázky odpovídáme brzy, aby se z jednotlivých dílů stal zatížitelný celek.
To je zvlášť rozhodující u multiplatformních projektů. Desktopový klient na Windows, macOS nebo Linux nesmí doménově znamenat něco jiného než doprovodný REST-server nebo pozadní služba. Proto navrhujeme datový model, procesy, oprávnění, integrace a provoz vždy dohromady. Tak vzniká architektura, ve které klienti, služby a servery mluví stejným jazykem.
Náš princip
Technologie pro nás není náboženství. Rozhodující je, aby architektura, schopnost týmu, provoz a budoucí rozšíření odpovídaly podniku. Nevyhrává nejhlasitější platforma, ale ta, se kterou lze smysluplně řídit riziko, udržovatelnost a růst.
Některé úkoly řešíme cíleně s Delphi, protože tam může narůst doménová logika, výkonné klienty a multiplatformnost uplatnit své přednosti. Jiné požadavky lépe sedí na C#, na služby, na portál nebo na kombinaci obojího. Dobrá architektura nevzniká z módy, ale z jasnosti: která část systému má jakou odpovědnost, jaká životnost se očekává, jak velký je tým, jak kritický je provoz a jaká rozšíření jsou v následujících letech realistická?
Právě tam pro nás začíná profesionální vývoj softwaru. Nechceme dodat jen něco, co dnes funguje, ale vytvořit technický základ, který bude i později přehledný, převzatelný a ekonomicky udržitelný.
Často kladené dotazy k technologii a architektuře
Technologická rozhodnutí musí sedět týmu, doméně a provozu. Proto tyto otázky nevyjasňujeme abstraktně, ale vždy na konkrétním systému.
Kdy je Delphi vhodné oproti kompletnímu novému řešení?
Vždy tehdy, když má být ekonomicky zachována vzniklá doménová logika, výkonné desktopové procesy a multiplatformní cíle místo lehkovážné výměny substance.
Kdy nasazujete navíc C#?
Především pro portály, webová backendy, REST-služby, integrace a servisně orientované části architektury, které se dobře provazují se stávajícími desktopovými systémy.
Jak důležitá je Layer-3 v praxi?
Velmi. Teprve čisté oddělení uživatelského rozhraní (UI), doménové logiky a přístupu k datům dělá modernizaci, testy, služby a budoucí přechody platforem zvládnutelnými.
Zvažujete nové platformy jako Windows 11 ARM64 brzy?
Ano. Nový cílový hardware a cesty nasazení se kontrolují včas, aby se z nich později nestaly nákladné mimořádné projekty.
Přečíst si souhrn dalších otázek
Těchto několik stručných odpovědí zůstává na této stránce. Na centrální FAQ‑landingpage téma navíc řadíme v souvislosti s architekturou, modernizací, platformami a provozem.