Технологичен профил
Преглед на нашата техническа основа
Delphi. C#. SQL. APIs.
Технологии, които са подходящи за бизнес логика, данни и експлоатация.
Не прилагаме технологии по мода, а според експлоатационната реалност, очакваната продължителност, нуждата от интеграция и възможностите на екипа. Решаващо не е модният термин, а дали системата по-късно ще остане лесна за експлоатация, разширяема и пригодна за прехвърляне.
Подходящ за бизнес-логика и мултиплатформени клиенти
Delphi е силен там, където съзрялата бизнес-логика, процесите близо до базата данни, отчетите и стабилните клиенти за Windows, macOS и Linux трябва да се поддържат в дългосрочен план.
Вижте Delphi
C#
Подходящ за REST, услуги и портали
C# използваме, когато портали, модерни бекенд услуги, REST-API-та и интеграции трябва да се свържат безпроблемно със съществуващите корпоративни системи.
Вижте C#
Архитектура
Layer-3 вместо монолитно наследство
Умишлено разделяме потребителския интерфейс, бизнес-логиката и достъпа до данни, за да останат промените планируеми и да не се налага новите услуги да се изграждат в противоречие със съществуващото.
Вижте Layer-3
Платформи
Windows 11 ARM64 още в проектирането
Освен класическите x64 цели, рано вземаме предвид актуални платформи като Windows 11 ARM64, за да не се превърнат новият хардуер и разгръщанията впоследствие в отделен проект.
Вижте ARM64
Кога коя посока е целесъобразна
Delphi е целесъобразен, когато
- съществуващата бизнес-логика трябва да продължи да се използва,
- сложните десктоп процеси трябва да останат стабилни,
- клиенти за Windows, macOS и Linux трябва да бъдат създадени върху обща предметна основа.
C# е целесъобразен, когато
- се изграждат REST-сървъри и услуги,
- API-та и външни интеграции са в центъра на вниманието,
- необходими са модерни сервизно-ориентирани архитектури.
Хибридният подход е целесъобразен, когато
- съществуващи приложения и нови портали трябва да работят заедно,
- десктоп, услуги и уеб използват една и съща данниова база,
- модернизацията трябва да се извърши стъпка по стъпка и като Layer-3-структура.
Delphi-модернизация в практиката
Когато старо Delphi-приложение все още има предметна стойност, не модернизираме на сляпо. Първо анализираме как системата реално работи, кои процеси поддържа, къде прекъсват потоките от данни и кои наследени проблеми спъват експлоатацията. От това произтича път за модернизация, който не само изглежда добре на хартия, но и остава приложим в ежедневието.
В много развити приложения истинската стойност не е в интерфейса, а в години на бизнес-логика, специални правила, изключения и експертни знания. Тази субстанция не се изхвърля лекомислено. Ние ясно разделяме отговорностите, реорганизираме базата данни, заменяме старите пътища за достъп, създаваме нови REST-интерфейси и при необходимост допълваме клиенти за Windows, macOS и Linux върху една и съща предметна основа. По този начин не се получава рязък скок, а проследима еволюция с ясен технически профил.
Често това означава и да приведем исторически развилите се монолити в форма, която да бъде обслужваема, тестируема и разширяема. Достъпът до данни се стабилизира, бизнес-логиката се извежда от кода на интерфейса, интерфейсите стават планирани и бъдещите разширения не трябва вече да се борят срещу наличното. Целта не е козметична модернизация, а система, която отново дава на фирмата възможност за нови изисквания.
Услуги и сървъри като част от същата архитектура
Много корпоративни системи днес имат нужда не само от клиент, но и от фонoви услуги, Windows- или Linux-услуги и REST-сървъри. Именно поради това не планираме тези части като последващо надстрояване, а като част от същата архитектура. Услуга, която се добавя по-късно по някакъв начин, почти винаги се превръща в специален случай.
Когато данни трябва да се обработват разпределено, когато се предоставят интерфейси, се извършват експорти, се наблюдават импорти или задачи трябва да се изпълняват по график на заден план, техническата отговорност трябва да е изяснена от самото начало. Кои части работят в клиента, кои в услугата, кои на сървъра, как грешките стават видими, как промените на състоянието се проследяват, как бизнес-логиката остава консистентна? На тези въпроси отговаряме рано, за да се сглоби от отделни блокове надеждна цялостна система.
Това е особено решаващо при мултиплатформени проекти. Един десктоп клиент на Windows, macOS или Linux не бива да има различно предметно значение от съпътстващ REST-сървър или фонова услуга. Затова мислим модел на данните, процесите, правата, интеграциите и експлоатацията винаги заедно. Така възниква архитектура, в която клиенти, услуги и сървъри говорят един и същи език.
Нашият принцип
Технологията за нас не е вярвам система. Решаващо е, че архитектурата, способността на екипа, експлоатацията и бъдещите разширения пасват на компанията. Не най-шумната платформа печели, а тази, с която рискът, поддържането и растежът могат да се управляват разумно.
Някои задачи решаваме съзнателно с Delphi, защото там съзрялата бизнес-логика, производителните клиенти и мултиплатформеността демонстрират силни страни. Други изисквания пасват по-добре на C#, на услуги, на портал или на комбинация от тях. Добрата архитектура не произтича от мода, а от яснота: коя част от системата носи каква отговорност, каква продължителност на живота е очаквана, колко голям е екипът, колко критична е експлоатацията и кои разширения реалистично ще се появят в следващите години?
Точно там за нас започва професионалната разработка на софтуер. Не искаме само да доставим нещо, което работи днес, а да създадем техническа основа, която и по-късно ще бъде проследима, поемаема и икономически поддържаема.
Често задавани въпроси за технологии и архитектура
Технологичните решения трябва да пасват на екипа, на предметността и на експлоатацията. Именно затова изясняваме тези въпроси не абстрактно, а винаги при конкретната система.
Кога Delphi е целесъобразен спрямо пълна нова платформа?
Винаги когато зрелата предметна логика, производителните десктоп процеси и целите за мултиплатформеност трябва да се продължат икономически, вместо същественото да се замени лекомислено.
Кога прилагате допълнително C#?
Предимно за портали, уеб бекендове, REST-услуги, интеграции и сервизно-ориентирани архитектурни части, които се вписват добре със съществуващите десктоп системи.
Колко важен е Layer-3 на практика?
Много. Само ясното разделяне на UI, бизнес-логиката и достъпа до данни прави модернизацията, тестовете, услугите и бъдещите смени на платформи управляеми.
Взимате ли предвид нови платформи като Windows 11 ARM64 рано?
Да. Новата целева хардуер и пътища за деплой се проверяват рано, за да не се превърнат по-късно в скъпи специални проекти.
Прочетете събраните допълнителни въпроси
Тези кратки отговори остават тук на страницата. На централната FAQ-Landingpage поставяме темата допълнително в контекста на архитектура, модернизация, платформи и експлоатация.