Darbo eiga
Kontroliuojami būsenų perėjimai
Užklausų būsenos keičiamos per atskirą darbo eigos logiką. Netinkami perėjimai atmetami, todėl sistemoje negalima savavališkai keisti būsenų.
← Grįžti į projektus
Produkcinis projektas
Service Desk
Produkcinė paslaugų valdymo sistema, sukurta naudojant Laravel ir orientuota į struktūrizuotą užklausų darbo eigą, teises, integracijas, automatizavimą ir lengvai prižiūrimą backend architektūrą.
Tipas
Paslaugų valdymo sistema
Pagrindinis dėmesys
Backend architektūra ir integracijos
Būsena
Baigtas
01 / Projektas
Projektas
Service Desk yra į backend orientuota pagalbos ir užklausų valdymo sistema, sukurta aplink aiškiai apibrėžtą užklausos gyvavimo ciklą ir atskirtas naudotojų atsakomybes.
Sistema palaiko tris pagrindinius vaidmenis: Requester, Agent ir Administrator. Kiekvienas vaidmuo turi savo teises ir atsakomybes užklausų darbo eigoje.
Requester gali kurti ir stebėti savo užklausas, Agent gali dirbti su jam priskirtomis užklausomis ir valdyti jų eigą, o Administrator turi platesnes naudotojų, priskyrimų ir sistemos operacijų valdymo teises.
Projektas buvo kuriamas kaip realistiška produkcinė sistema, o ne paprastas CRUD sprendimas. Pagrindinis dėmesys skirtas prognozuojamoms verslo taisyklėms, lengvai prižiūrimam backend kodui, atsekamiems pakeitimams, integracijoms ir patikimam sistemos elgesiui keičiantis jos būsenai.
02 / Pagrindinis backend
Pagrindinis backend
Sistemos branduolys paremtas aiškiomis užklausų darbo eigos taisyklėmis, neleidžiant savavališkai keisti būsenų tiesiogiai valdikliuose ar modeliuose.
Autorizacija
Teisės pagal vaidmenis
Laravel policies apibrėžia, ką Requester, Agent ir Administrator gali atlikti su užklausomis, komentarais, priedais ir darbo eigos operacijomis.
Programos logika
Į paslaugas orientuotas dizainas
Verslo operacijos, tokios kaip būsenų perėjimai, pranešimai ir išorinės integracijos, išskirtos į atskiras paslaugas, todėl valdikliai lieka orientuoti į užklausų apdorojimą.
Nuoseklumas
Duomenų bazės transakcijos
Operacijos, kurios keičia kelias sistemos būsenos dalis, vykdomos duomenų bazės transakcijose, kad visi susiję pakeitimai būtų įvykdyti arba atšaukti kartu.
Domeno struktūra
Enums ir aiškios būsenos
Užklausų būsenos ir prioritetai aprašyti naudojant PHP enums, taip sumažinant išsibarsčiusių tekstinių reikšmių kiekį ir palengvinant domeno taisyklių supratimą bei priežiūrą.
Priskyrimas
Užklausos atsakomybė
Užklausos gali būti priskiriamos Agent naudotojams išsaugant ryšį su pradiniu Requester, todėl sistema aiškiai atskiria užklausos kūrėją nuo ją vykdančio darbuotojo.
03 / Auditas ir pranešimai
Auditas ir pranešimai
Svarbūs veiksmai su užklausomis yra atsekami, o pranešimai apdorojami už pagrindinio HTTP užklausos srauto ribų, kad verslo operacijos išliktų patikimos ir greitos.
Audito istorija
Žmogui suprantama užklausos istorija
Užklausų pakeitimai registruojami atskirame istorijos sluoksnyje, išsaugant informaciją apie tai, kas atliko veiksmą, kada jis buvo atliktas ir kas pasikeitė.
Vietoje neapdorotų duomenų bazės reikšmių rodymo naudotojui sistema pakeitimus paverčia suprantamais istorijos įrašais, tokiais kaip būsenos pakeitimai, priskyrimai ir prioriteto atnaujinimai.
Pavyzdžiai
/
Būsena pakeista iš New į In Progress
/
Užklausa priskirta Agent naudotojui
/
Prioritetas pakeistas iš Medium į High
Bendradarbiavimas
Komentarai
Naudotojai gali aptarti užklausos eigą tiesiogiai sistemoje, išlaikant komunikaciją susietą su konkrečia užklausa ir naudotoju.
Failai
Privatūs priedai
Užklausų priedai saugomi privačiai ir pasiekiami per programos autorizaciją, o ne pateikiami kaip neribotai viešai prieinami failai.
Pranešimai
Pristatymas per eilę
Pranešimai siunčiami per queue, todėl išorinis jų pristatymas neblokuoja pagrindinės naudotojo užklausos.
Patikimumas
Veiksmai po transakcijos
Šalutiniai veiksmai, priklausantys nuo išsaugotos programos būsenos, vykdomi tik sėkmingai užbaigus duomenų bazės transakciją. Tai apsaugo nuo pranešimų išsiuntimo apie pakeitimus, kurie vėliau buvo atšaukti.
04 / Integracijos
Integracijos
Išorinės sistemos integruojamos per atskiras programos paslaugas ir patikrintus įeinančių užklausų endpointus, todėl konkrečių tiekėjų logika lieka atskirta nuo pagrindinio užklausų domeno.
API
REST API
Sistema pateikia REST API darbui su Service Desk duomenimis už Blade sąsajos ribų, kartu pakartotinai naudodama tas pačias autorizacijos ir verslo taisykles kaip pagrindinė programa.
Jira
Jira integracija
Service Desk gali komunikuoti su Jira per atskirą integracijos sluoksnį, todėl išorinė užduočių sistema prijungiama neperkeliant Jira specifinės logikos į pagrindinę užklausų darbo eigą.
GitHub
GitHub integracija
GitHub integracija leidžia su saugykla susijusiems įvykiams ir išoriniams kūrimo procesams sąveikauti su sistema per atskirą tiekėjo paslaugą, tiesiogiai nesusiejant jų su užklausų modeliais ir valdikliais.
Webhooks
Patikrinti įeinantys įvykiai
Gaunamos webhook užklausos patikrinamos prieš priimant jų duomenis, todėl nepatikimos užklausos nėra laikomos teisėtais išorinių tiekėjų įvykiais.
Patikimumas
Idempotentinis apdorojimas
Webhook apdorojimas sukurtas taip, kad toleruotų pasikartojančius pristatymus. Pakartotiniai išorinio tiekėjo įvykiai atpažįstami, todėl tas pats įvykis nesukuria dubliuotų sistemos pakeitimų.
Architektūra
Tiekėjų izoliacija
Išoriniai tiekėjai atskirti aiškiomis integracijos ribomis. Tai padeda išlaikyti programos domeną nepriklausomą ir palengvina konkretaus tiekėjo logikos keitimą, testavimą bei plėtimą.
05 / AI integracija
AI integracija
AI funkcionalumas integruotas kaip programos galimybė, o ne tiesiogiai įrašytas į užklausų valdiklius ar nuolat susietas su vienu išoriniu modelių tiekėju.
Įgyvendinimas palieka AI sugeneruotus pasiūlymus naudotojo kontrolėje. Sugeneruotas turinys gali padėti darbo eigoje, tačiau sistemos būsena nėra keičiama automatiškai be aiškaus žmogaus veiksmo.
Architektūra
Nuo tiekėjo nepriklausomas dizainas
AI funkcionalumas pateikiamas per programos lygio abstrakciją, užuot išsklaidžius konkretaus tiekėjo SDK kvietimus po visą kodo bazę. Likusi sistema priklauso nuo bendros sąsajos, o ne nuo vieno konkretaus AI tiekėjo.
Tiekėjai
OpenAI ir Groq
Integracija palaiko kelis AI tiekėjus, įskaitant OpenAI ir Groq. Tiekėją galima pakeisti nereikalaujant, kad pats užklausų domenas suprastų konkretaus tiekėjo API.
Darbo eiga
Human-in-the-loop
AI rezultatas laikomas pasiūlymu, o ne autoritetingu sistemos sprendimu. Naudotojai peržiūri sugeneruotą turinį ir patys nusprendžia, ar jis turi tapti realios užklausos darbo eigos dalimi.
Atskyrimas
AI už pagrindinio domeno ribų
Užklausų darbo eigos taisyklės išlieka deterministinės ir nepriklausomos nuo AI prieinamumo. Jei AI tiekėjas nepasiekiamas, pagrindinė Service Desk sistema gali toliau veikti normaliai.
Projektavimo principas
AI padeda naudotojui. Jis netampa verslo logika be aiškaus žmogaus sprendimo.
06 / Testavimas ir patikimumas
Testavimas ir patikimumas
Automatiniai testai saugo programos darbo eigą, autorizacijos taisykles ir integracijas, todėl pakeitimus galima atlikti nepasikliaujant vien rankiniu tikrinimu.
Testai
315
automatiniai testai
Patikrinimai
979
assertions
Pipeline
CI
automatinis tikrinimas
PHPUnit
Feature ir unit testai
Automatiniai testai tikrina verslo elgseną skirtingais lygiais, įskaitant atskiras domeno taisykles ir pilnas programos darbo eigas.
Integracijos
Išorinės elgsenos tikrinimas
Su integracijomis susijusi elgsena testuojama nereikalaujant, kad kiekvienas testas priklausytų nuo veikiančių trečiųjų šalių paslaugų. Taip testai išlieka pakartojami ir tinkami automatiniam vykdymui.
CI
Automatinis projekto tikrinimas
CI pipeline vykdo automatinius patikrinimus prieš priimant pakeitimus, suteikdamas papildomą saugumo sluoksnį šalia lokalaus kūrimo ir rankinės peržiūros.
Kodo kokybė
Laravel Pint
Laravel Pint naudojamas kaip projekto tikrinimo dalis, kad PHP kodo formatavimas išliktų nuoseklus visoje kodo bazėje.
Build
Production assetų tikrinimas
Frontend production build tikrinamas kartu su backend patikromis, kad diegimas nepriklausytų nuo tik development aplinkoje veikiančio assetų elgesio.
Galutinis patikrinimas
315 testų, 979 assertions, Laravel Pint, production asset build ir CI patikrinimas sėkmingai užbaigti.
07 / Production ir diegimas
Production ir diegimas
Sistema įdiegta kaip reali production sistema su nuolatine failų saugykla, foniniu apdorojimu, HTTPS ir išoriniu el. pašto pristatymu.
Hostingas
Diegimas Railway
Sistema įdiegta Railway platformoje naudojant atskirus pagrindinės programos ir foninio worker procesus.
Duomenų bazė
MySQL
Production sistemos duomenys saugomi MySQL, o migrations naudojamos tam, kad duomenų bazės struktūra išliktų vienoda skirtingose aplinkose.
Foninės užduotys
Atskiras queue worker
Queue užduotys vykdomos atskirame worker procese, todėl pranešimai ir kitos asinchroninės operacijos apdorojamos nepriklausomai nuo web užklausų.
Saugykla
Nuolat saugomi privatūs failai
Privatūs užklausų priedai saugomi nuolatinėje saugykloje, todėl įkelti failai išlieka po sistemos redeploy ir kartu lieka apsaugoti programos autorizacijos.
Saugumas
HTTPS ir saugūs slapukai
Production aplinkoje naudojamas HTTPS su nuosavu domenu ir saugia slapukų konfigūracija, tinkama šifruotoms naršyklės sesijoms.
Būsena
Programos health endpoint
Laravel health endpoint naudojamas baziniams diegimo ir sistemos pasiekiamumo patikrinimams.
El. paštas
Siuntimas per Resend
Transakciniai sistemos el. laiškai siunčiami per Resend naudojant sukonfigūruotą production siuntėjo adresą.
Domenas
desk.kotov.lt
Sistema pasiekiama per atskirą nuosavą subdomeną, todėl tai yra realiai viešai veikianti sistema, o ne tik lokali demonstracinė aplinka.
Production aplinka
Railway, MySQL, atskiras queue worker, nuolatinė privati failų saugykla, HTTPS, health patikrinimai ir transakcinis el. pašto siuntimas.
08 / Technologijų stack
Technologijų stack
Projektas sujungia įprastą Laravel programos stack su foniniu apdorojimu, išorinėmis integracijomis ir produkcijai skirtais inžineriniais įrankiais.
Backend
PHP
Laravel
REST API
Laravel Sanctum
Duomenys
MySQL
Eloquent ORM
Duomenų bazės migracijos
Privati failų saugykla
Integracijos
Jira
GitHub
OpenAI
Groq
Resend
Inžinerija
PHPUnit
Laravel Pint
Docker
Laravel Sail
CI
09 / Rezultatas
Ką parodo šis projektas
Service Desk parodo gebėjimą projektuoti ir prižiūrėti backend funkcionalumą, kuris neapsiriboja paprastomis CRUD operacijomis: aiškios verslo taisyklės, autorizacija, asinchroninis apdorojimas, integracijos ir production diegimas.
Projektas taip pat sprendžia problemas, kurios tampa svarbios realiose sistemose: transakcinį nuoseklumą, auditą, pasikartojančius išorinius įvykius, privačią prieigą prie failų, automatinius testus ir gedimų izoliavimą tarp skirtingų sistemos komponentų.
Struktūrizuotos verslo darbo eigos
Autorizacija pagal vaidmenis
Į paslaugas orientuota backend architektūra
Patikimos išorinės integracijos
Automatinis testavimas ir CI
Production diegimas ir eksploatavimas