Tehnološki profil
Pregled naše tehnične osnove
Tehnologij ne uporabljamo po modi, temveč glede na realnost obratovanja, življenjsko dobo, potrebe po integraciji in sposobnost ekipe. Odločilno ni geslo, temveč ali sistem kasneje ostane čisto upravljiv, razširljiv in prevzemljiv.
Močan za poslovno logiko in večplatformne odjemalce
Delphi je močan tam, kjer se morajo zrasla poslovna logika, procesi blizu podatkovni bazi, poročila in stabilni odjemalci za Windows, macOS in Linux dolgoročno nadalje razvijati.
Oglejte si Delphi
C#
Močan za REST, storitve in portale
C# uporabljamo, ko morajo portali, sodobne zaledne storitve, REST-API-ji in integracije čisto priključiti na obstoječe poslovne sisteme.
Oglejte si C#
Arhitektura
Layer-3 namesto monolitne zapuščine
Zavestno ločimo uporabniški vmesnik, poslovno logiko in dostop do podatkov, da spremembe ostanejo načrtljive in novih storitev ni treba graditi proti obstoječemu stanju.
Oglejte si Layer-3
Platforme
Windows 11 ARM64 upoštevati že od začetka
Poleg klasičnih x64-ciljev zgodaj upoštevamo aktualne platforme, kot je Windows 11 ARM64, da nova strojna oprema in nameščanja kasneje ne postanejo poseben projekt.
Oglejte si ARM64
Kdaj je katera smer smiselna
Delphi je smiselno, če
- mora obstoječa domenska logika živeti naprej,
- morajo kompleksni namizni procesi ostati stabilni,
- morajo nastati odjemalci za Windows, macOS in Linux na skupni strokovni osnovi.
C# je smiselno, če
- se vzpostavljajo REST-strežniki in storitve,
- so v ospredju API-ji in zunanje integracije,
- so potrebne sodobne servisne arhitekture.
Hibrid je smiseln, če
- morajo obstoječe aplikacije in novi portali sodelovati,
- namizje, storitve in splet uporabljajo isto podatkovno osnovo,
- naj modernizacija poteka postopno in kot struktura Layer-3.
Modernizacija Delphi v praksi
Če je stara aplikacija Delphi strokovno še vredna, je ne moderniziramo na slepo. Najprej analiziramo, kako sistem dejansko deluje, katere procese podpira, kje se podatkovni tokovi prekinjajo in katere zapuščine zavirajo obratovanje. Iz tega nastane pot modernizacije, ki ne deluje čisto le na papirju, temveč v vsakdanjem delu ostane vzdržna.
V številnih z leti zraslih aplikacijah prava vrednost ni v uporabniškem vmesniku, temveč v letih domenske logike, posebnih pravil, izjem in izkušenj. Te osnove se ne zavrže lahkomiselno. Odgovornosti jasno ločimo, na novo uredimo podatkovno bazo, opustimo stare načine dostopa, vzpostavimo nove REST-vmesnike in po potrebi dopolnimo odjemalce za Windows, macOS in Linux na isti poslovni osnovi. Tako ne nastane trd prelom, temveč razumljiv razvoj z jasno tehnično opredelitvijo.
Pogosto to pomeni tudi, da zgodovinsko zrasle monolite ponovno spravimo v obliko, ki postane vzdrževana, testabilna in razširljiva. Dostop do podatkov stabiliziramo, poslovno logiko izločimo iz kode uporabniških vmesnikov, vmesniki postanejo načrtljivi in prihodnjih razširitev ni več treba izsiljevati proti obstoječemu stanju. Cilj ni kozmetična modernizacija, temveč sistem, ki podjetju ponovno omogoči prostor za nove zahteve.
Storitve in strežniki kot del iste arhitekture
Številni poslovni sistemi danes ne potrebujejo le odjemalca, temveč tudi ozadnje storitve, Windows- ali Linux-storitve ter REST-strežnike. Prav zato teh delov ne načrtujemo kot naknadni dodatek, temveč kot del iste arhitekture. Storitev, ki se kasneje nekako priključi, skoraj vedno postane posebnost.
Če je treba podatke obdelovati porazdeljeno, zagotavljati vmesnike, izvajati izvoze, nadzorovati uvoze ali v ozadju časovno krmiljeno izvajati naloge, mora biti tehnična odgovornost razjasnjena že od začetka. Kateri deli tečejo v odjemalcu, kateri v storitvi, kateri na strežniku, kako so napake vidne, kako so spremembe stanja sledljive, kako ostane poslovna logika konsistentna? Na ta vprašanja odgovorimo zgodaj, da iz posameznih gradnikov nastane zanesljiv celovit sistem.
To je še posebej odločilno pri večplatformskih projektih. Namizni odjemalec na Windows, macOS ali Linux ne sme poslovno pomeniti nečesa drugega kot spremljajoči REST-strežnik ali ozadnja storitev. Zato podatkovni model, procese, pravice, integracije in obratovanje vedno obravnavamo skupaj. Tako nastane arhitektura, v kateri odjemalci, storitve in strežniki govorijo isti jezik.
Naše načelo
Tehnologija za nas ni sistem verovanja. Odločilno je, da se arhitektura, sposobnost sodelovanja v ekipi, obratovanje in prihodnje razširitve ujemajo s podjetjem. Ne zmaga najglasnejša platforma, temveč tista, s katero je mogoče smiselno upravljati tveganje, vzdržljivost in rast.
Nekatere naloge zavestno rešujemo z Delphi, ker tam zrasla poslovna logika, zmogljivi odjemalci in večplatformskost pokažejo svoje prednosti. Druge zahteve se bolje ujemajo z C#, s storitvami, s portalom ali s kombinacijo obojega. Dobra arhitektura ne nastane iz mode, temveč iz jasnosti: katero odgovornost ima kateri del sistema, kakšna življenjska doba je pričakovana, kako velika je ekipa, kako kritično je obratovanje in katere razširitve bodo v naslednjih letih realno prišle?
Tam se za nas začne profesionalni razvoj programske opreme. Ne želimo le dostaviti nečesa, kar danes deluje, temveč ustvariti tehnično osnovo, ki bo tudi kasneje razumljiva, prevzemljiva in ekonomsko vzdržna za vzdrževanje.
Pogosta vprašanja o tehnologiji in arhitekturi
Tehnološke odločitve se morajo ujemati z ekipo, domeno in obratovanjem. Prav zato teh vprašanj ne obravnavamo abstraktno, temveč vedno na konkretnem sistemu.
Kdaj je Delphi smiselna v primerjavi s popolno novo platformo?
Vedno takrat, ko je treba ekonomsko nadalje razvijati zraslo domensko logiko, zmogljive namizne procese in cilje več platform, namesto da bi se substanco nepremišljeno nadomestilo.
Kdaj dodatno uporabljate C#?
Predvsem za portale, spletne backende, storitve REST, integracije in dele storitveno usmerjene arhitekture, ki jih je mogoče dobro povezati z obstoječimi namiznimi sistemi.
Kako pomemben je Layer-3 v praksi?
Zelo. Šele čista ločitev UI, poslovne logike in dostopa do podatkov naredi modernizacijo, teste, storitve in prihodnje menjave platform obvladljive.
Ali nove platforme, kot je Windows 11 ARM64, upoštevate zgodaj?
Da. Nova ciljna strojna oprema in poti uvajanja se preverijo zgodaj, da iz tega pozneje ne nastanejo dragi posebni projekti.
Dodatna vprašanja preberite zbrano
Ti kratki odgovori ostanejo tukaj na strani. Na osrednji pristajalni strani FAQ temo dodatno umestimo v kontekst arhitekture, modernizacije, platform in obratovanja.