Tehnoloģiju profils
Mūsu tehniskā bāze — pārskats
Delphi. C#. SQL. APIs.
Tehnoloģijas, kas atbilst nozares loģikai, datiem un darbībai.
Tehnoloģija attēlos
Tehnoloģiju lēmumi pie mums kļūst redzami caur mērķa arhitektūru.
Izšķirošais nav modīgs termins, bet gan tas, kā platforma, servisi un slāņi vēlāk sadarbojas. Šīs skices padara virzienu taustāmu.
Shared Core vairākiem mērķiem
Multiplatforma ir jēgpilna, ja vairāki klienti izmanto vienu un to pašu nozares loģiku un tā nenovirzās.
* Izmantotie platformu nosaukumi un preču zīmes pieder attiecīgajiem tiesību īpašniekiem.
C# un pakalpojumi kā papildinājums
Portāli, REST un pakalpojumi papildina kodolu tur, kur tīmekļa un darbības loģika kļūst izteiktāka.
Mērķa aparatūru ņemt vērā jau agrīnā posmā.
Platformu pārejas uz ARM64 jārisina arhitektūrā un izvietošanā, pirms tās kļūst par atbalsta problēmu.
Atbilstoši pakalpojumu un tehnoloģiju ceļi
Svarīgas padziļināšanas par šo tēmu
Mēs tehnoloģijas neieviešam pēc modes, bet pēc darbības realitātes, kalpošanas ilguma, integrācijas vajadzības un komandas spējām. Izšķiroši nav sauklis, bet vai sistēma vēlāk paliks korekti uzturama, paplašināma un pārņemama.
Spēcīgs biznesa loģikai un multiplatformu klientiem
Delphi ir spēcīgs tur, kur saglabājusies domēna loģika, datubāzei tuvi procesi, atskaites un stabilie klienti priekš Windows, macOS un Linux jāuztur ilgtermiņā.
Delphi skatīt
C#
Spēcīgs priekš REST, servisiem un portāliem
C# izmantojam, ja portāli, mūsdienīgi backend-pakalpojumi, REST-API un integrācijas ir jāpieslēdz tīri esošajām uzņēmuma sistēmām.
C# skatīt
Arhitektūra
Layer-3 nevis monolītiskas mantojuma sistēmas
Mēs apzināti atdalām lietotāja saskarni, biznesa loģiku un datu piekļuvi, lai izmaiņas būtu plānojamas un jauni servisi nebūtu jāveido pretrunā esošajam.
Layer-3 skatīt
Platformas
Windows 11 ARM64 jau ņemt vērā
Bez klasiskajiem x64 mērķiem mēs agrīni ņemam vērā aktuālās platformas, piemēram, Windows 11 ARM64, lai jauna aparatūra un izvietojumi vēlāk nekļūtu par īpašu projektu.
ARM64 skatīt
Kad kura pieeja ir pamatota
Delphi ir lietderīgs, ja
- esošā domēna loģika jāturpina,
- sarežģīti darbvirsmas procesi jānodrošina stabilitāte,
- Windows-, macOS- un Linux-klienti jāizstrādā uz kopīgas funkcionālās bāzes.
C# ir lietderīgs, ja
- REST-serveri un servisi tiek veidoti,
- APIs un ārējās integrācijas ir centrā,
- mūsdienīgas servisu arhitektūras ir pieprasītas.
Hibrīds ir lietderīgs, ja
- esošās lietotnes un jaunie portāli ir jāvada kopā,
- darbvirsma, servisi un web izmanto vienu datu bāzi,
- modernizācija jāveic pakāpeniski un kā Layer-3-struktūra.
Delphi modernizācija praksē
Ja veca Delphi lietojumprogramma funkcionāli joprojām ir vērtīga, mēs nemodernizējam akli. Vispirms analizējam, kā sistēma patiesībā darbojas, kādus procesus tā atbalsta, kur datu plūsmas pārtrūkst un kādas mantojuma problēmas palēnina darbību. No tā izveidojas modernizācijas ceļš, kas ne tikai uz papīra izskatās kārtīgs, bet ikdienā saglabā savu dzīvotspēju.
Daudzās ilgstoši attīstītās lietojumprogrammās īstā vērtība nav lietotāja saskarnē, bet gadu laikā uzkrātajā biznesa loģikā, īpašajos noteikumos, izņēmumos un pieredzes zināšanās. Šo saturu nav saprātīgi izmest. Mēs skaidri atdalām atbildības, pārkārtojam datubāzi, aizstājam vecos piekļuves ceļus, izveidojam jaunas REST-saskarnes un pēc vajadzības papildinām klientus priekš Windows, macOS un Linux uz tās pašas nozaru bāzes. Tā nerodas straujš lūzums, bet saprotama tālākizstrāde ar skaidru tehnisku profilu.
Bieži tas arī nozīmē vēsturisku monolītu pārveidi tādā formā, kas ir uzturama, testējama un paplašināma. Datu piekļuve tiek stabilizēta, biznesa loģika tiek izņemta no saskarnes koda, saskarnes kļūst plānojamas un nākotnes paplašinājumiem vairs nav jāizcīnas pret esošo risinājumu. Mērķis nav kosmētiska modernizācija, bet sistēma, kas uzņēmumam atkal dod telpu jaunām prasībām.
Servisi un serveri kā tās pašas arhitektūras daļa
Daudzām uzņēmumu sistēmām šodien nepieciešams ne tikai klients, bet arī fona pakalpojumi, Windows- vai Linux-servisi un REST-serveri. Tieši tāpēc mēs šīs daļas neplānojam kā vēlāk pievienotu pielikumu, bet kā vienas un tās pašas arhitektūras sastāvdaļu. Serviss, kas tiek pievienots tikai vēlāk, gandrīz vienmēr kļūst par izņēmumu.
Ja dati jāapstrādā sadalīti, jānodrošina saskarnes, jāveic eksporti, jāuzrauga importi vai uzdevumi jāizpilda laika ziņā fonā, tehniskā atbildība jānosaka jau no sākuma. Kurš kods darbojas klientā, kurš — servisā, kurš — serverī, kā kļūdas tiek padarītas redzamas, kā stāvokļa izmaiņas tiek izsekojamas, kā nozaru loģika saglabā konsistenci? Uz šiem jautājumiem mēs atbildam agri, lai no atsevišķiem komponentiem radītu uzticamu kopējo sistēmu.
Tas ir īpaši izšķiroši multiplatformu projektos. Darbvirsmas klients uz Windows, macOS vai Linux nedrīkst nozaru ziņā domāt kaut ko citu nekā pavadošs REST-serveris vai fona pakalpojums. Tāpēc mēs vienmēr kopā domājam datu modeli, procesus, piekļuves tiesības, integrācijas un darbību. Tā rodas arhitektūra, kurā klienti, servisi un serveri runā vienu un to pašu valodu.
Mūsu pamatprincips
Tehnoloģija mums nav ticības sistēma. Izšķiroši ir, lai arhitektūra, komandas spēja, darbība un nākotnes paplašinājumi atbilstu uzņēmumam. Ne skaļākā platforma uzvar, bet tā, ar kuru iespējams pamatoti vadīt risku, uzturējamību un izaugsmi.
Dažas uzdevumus mēs apzināti risinām ar Delphi, jo tur uzkrātā biznesa loģika, veiktspējīgie klienti un multiplatformu spēja demonstrē savas priekšrocības. Citas prasības labāk atbilst C#, servisiem, portālam vai abu kombinācijai. Laba arhitektūra nerodas no modes, bet no skaidrības: kāda atbildība ir katrai sistēmas daļai, kāds ir sagaidāmais dzīves ilgums, cik liela ir komanda, cik kritisks ir darbības režīms un kādi paplašinājumi reāli gaidāmi nākamo gadu laikā?
Tur sākas mūsu profesionāla programmatūras izstrāde. Mēs vēlamies ne tikai piegādāt to, kas šodien darbojas, bet izveidot tehnisku pamatu, kas arī vēlāk būs izsekojams, pārņemams un ekonomiski uzturams.
Bieži uzdotie jautājumi par tehnoloģiju un arhitektūru
Tehnoloģiskie lēmumi ir jāpielāgo komandai, nozarei un ekspluatācijai. Tieši tāpēc šos jautājumus mēs neizlemjam abstrakti, bet vienmēr, ņemot vērā konkrēto sistēmu.
Kad Delphi ir lietderīgs salīdzinājumā ar pilnīgu jaunas platformas ieviešanu?
Tas attiecas uz situācijām, kad izveidojusies nozares loģika, veiktspējīgi darbvirsmas procesi un multiplatformu mērķi ir ekonomiski pamatotāk saglabājami, nekā sistēmas būtības vieglprātīga aizstāšana.
Kad papildus izmantojat C#?
Īpaši portāliem, tīmekļa back-endiem, REST-pakalpojumiem, integrācijām un pakalpojumu orientētām arhitektūras daļām, kas labi saplūst ar esošajām darbvirsmas sistēmām.
Cik svarīgs praksē ir Layer-3?
Ļoti. Tikai skaidra UI, biznesa loģikas un datu piekļuves atdalīšana padara modernizāciju, testus, pakalpojumus un nākotnes platformu pārejas pārvaldāmas.
Vai jaunas platformas, piemēram, Windows 11 ARM64, tiek ņemtas vērā agrīnā posmā?
Jā. Jaunā mērķa aparatūra un izvietošanas ceļi tiek pārbaudīti agrīnā stadijā, lai vēlāk no tiem nekļūtu dārgi atsevišķi projekti.
Vairāk jautājumu apkopojumā
Šīs īsās atbildes paliek šeit lapā. Galvenajā FAQ lapā mēs šo tēmu papildus sakārtosim saistībā ar arhitektūru, modernizāciju, platformām un ekspluatāciju.
Nākamais solis
Wenn Sie eine konkrete Modernisierung, API- oder Plattformfrage haben, sollten wir den technischen Zuschnitt frueh sauber einordnen.
Net-Base bewertet bestehende Systeme, Datenpfade, Schnittstellen und Zielplattformen nicht isoliert, sondern im Zusammenhang von Fachlogik, Betrieb und späterem Ausbau.
- Esošais stāvoklis, mērķa stāvoklis un tehniskie riski tiek kopīgi vērtēti.
- REST, datu piekļuve, portāli un izvēršana netiek atlikti kā vēlākas sekas.
- Jūs savlaicīgi redzat, kurš ceļš ir ekonomiski un darbības ziņā dzīvotspējīgs.