MDS Documentation

Driveflow CRM este o platformă inteligentă, web-based, care oferă școlilor de șoferi de orice dimensiune precizie, eficiență și simplitate în gestionarea activităților zilnice. Este un sistem ușor, susținut de inteligență artificială, care pune automatizarea și personalizarea în centrul procesului de formare rutieră.

Cu Driveflow, elevii își pot personaliza parcursul de învățare, instructorii economisesc timp prin automatizare, iar școlile beneficiază de programări fluide, generare automată de chitanțe și instrumente moderne de comunicare — totul fără efort. Driveflow CRM nu doar administrează o școală de șoferi, ci o duce mai departe, modernizând complet experiența educației rutiere.

Driveflow CRM este conceput pentru:

• elevii care doresc să se perfecționeze după fiecare curs, indiferent de nivelul de experiență;
• instructorii care vor să-și reducă volumul de muncă la jumătate până la sfârșitul zilei;
• școlile de șoferi care își doresc programe ordonate, operațiuni fluide și fără bătăi de cap.

Noi:

• te ajutăm să alegi cea mai potrivită mașină și instructor în funcție de stilul tău de învățare;
• facilităm feedbackul direct între elev și instructor;
• generăm programe care se potrivesc perfect atât elevilor, cât și instructorilor.

Driveflow CRM este o soluție flexibilă și completă pentru orice școală de șoferi — indiferent de mărime, echipă sau buget. Prin microservicii, platforma generează automat chitanțe și oferă elevilor instrumentele necesare pentru a-și modela propria experiență de învățare, asigurând că fiecare curs își atinge scopul — fără ca tu să miști un deget.

Scheduling Driving Lessons Andrei este administratorul unei scoli auto din Bucuresti. El este responsabil de programarea lectiilor de conducere pentru elevi si de alocarea instructorilor si vehiculelor disponibile. In prezent, mare parte din aceste programari se realizeaza manual, folosind tabele Excel si apeluri telefonice. Acest proces duce frecvent la erori, suprapuneri si timpi morti intre sedinte.

Pentru a rezolva aceasta problema, scoala adopta un nou sistem digital care permite atat instructorilor, cat si elevilor, sa gestioneze programarile online. Instructorii isi pot marca disponibilitatea saptamanala in sistem, iar elevii pot vizualiza intervalele libere si pot face rezervari direct din aplicatie. Sistemul aloca automat vehiculele disponibile, verifica conflictele si trimite notificari tuturor partilor implicate. Daca un elev doreste sa reprogrameze o sedinta, o poate face din contul sau personal, iar sistemul actualizeaza automat orarul. In acest fel, administratorul reduce timpul petrecut cu planificarea manuala si optimizeaza utilizarea flotei si a personalului.

Instructor’s Daily Schedule Mihai este instructor auto la aceeasi scoala. Inainte, el isi nota programul zilnic intr-un caiet si verifica manual cine este elevul si ce masina este disponibila. De multe ori, unele sedinte se suprapuneau sau masina atribuita nu era libera.

Prin noul sistem, Mihai se autentifica pe platforma si acceseaza un panou digital care afiseaza programul zilnic. Fiecare sedinta contine numele elevului, modelul vehiculului si locul de intalnire. Daca un elev anuleaza o sedinta, programul se actualizeaza automat. Mihai poate, de asemenea, sa marcheze perioadele in care este indisponibil, iar sistemul nu va permite programari in acele intervale. Aceasta functionalitate elimina confuziile si ii permite sa-si gestioneze eficient timpul.

Tracking Student Progress Irina este instructor auto cu experienta, responsabila de formarea elevilor inaintea examenului practic. Ea obisnuia sa tina evidenta progresului pe hartie, notand observatii dupa fiecare lectie. Aceste foi se pierdeau adesea, iar elevii nu aveau acces la feedback clar.

Prin noul sistem, dupa fiecare sedinta, Irina acceseaza formularul digital standardizat, identic cu cel folosit la examenul auto, care contine 21 de puncte de evaluare. Ea completeaza observatiile pentru fiecare criteriu si adauga comentarii suplimentare. Dupa salvare, elevul primeste o notificare si poate consulta feedback-ul in contul sau. Sistemul analizeaza istoricul greselilor si sugereaza exercitii personalizate pentru urmatoarele sedinte. Astfel, procesul devine transparent, digital si orientat pe progresul real al elevului.

Automated Billing and Payment Records Anca este administrator financiar in cadrul scolii auto. Ea trebuie sa gestioneze facturile pentru sute de elevi lunar. Sistemul vechi presupunea emiterea manuala a documentelor si completarea rapoartelor contabile, ceea ce ducea la intarzieri si erori.

In noul sistem, fiecare plata efectuata de elev genereaza automat o factura digitala. Elevul poate accesa istoricul platilor din contul sau, descarcand facturile in format PDF. Anca are posibilitatea sa exporte rapoarte contabile in formate CSV, Excel sau PDF, utile pentru raportare catre autoritati. Sistemul reduce timpul de procesare, elimina erorile umane si ofera o evidenta clara a tuturor tranzactiilor.

Vehicle Fleet Management Bogdan este responsabil de intretinerea vehiculelor scolii auto. In sistemul actual, el foloseste tabele pentru a urmari datele de revizie, asigurari si kilometraj. Deseori, notificarea expirarii RCA sau a reviziei ajunge prea tarziu, ducand la suspendarea temporara a vehiculului.

Prin noul sistem, fiecare vehicul are un profil digital cu istoricul complet al reviziilor, defectiunilor si verificarilor. Bogdan primeste alerte automate inainte de expirarea documentelor si poate planifica mentenanta preventiv. De asemenea, administratorul poate vizualiza gradul de utilizare al fiecarui vehicul si poate optimiza alocarea acestora intre instructori. In acest mod, flota este mentinuta in stare optima, iar costurile sunt reduse.

Performance Analytics and Reporting Ioana, directorul scolii auto, doreste o imagine clara asupra activitatii zilnice. Ea are nevoie de date despre numarul de sedinte efectuate, rata de promovare si performanta instructorilor. In trecut, aceste informatii se colectau manual, prin centralizarea fisierelor Excel.

Noul sistem ofera un tablou de bord interactiv cu rapoarte vizuale, grafice comparative si heatmap-uri. Ioana poate analiza performanta individuala a instructorilor, progresul mediu al elevilor si utilizarea vehiculelor. Printr-un singur click, poate exporta rapoarte lunare pentru managementul intern si autoritati. Aceasta functionalitate transforma analiza scolii intr-un proces rapid si strategic.

AI-Based Learning Recommendations Vlad este elev la scoala auto si are dificultati in manevrele de parcare. Dupa cateva sedinte, sistemul detecteaza ca el repeta aceleasi greseli in evaluarea instructorului. Modulul AI analizeaza istoricul greselilor si ii recomanda videoclipuri, articole si exercitii practice pentru imbunatatire. Vlad poate accesa aceste materiale direct din contul sau si se poate antrena inaintea urmatoarei lectii. In timp, sistemul monitorizeaza progresul si actualizeaza recomandarile. Astfel, procesul de invatare devine personalizat si eficient.

Inconsistența mediilor de rulare (ex: „funcționează local, dar nu pe server”) și dificultatea de a scala componentele individuale (API vs. worker) în funcție de trafic.

• Implementarea unei arhitecturi complet containerizate folosind Docker și docker-compose.

• Fiecare serviciu (API, Accountant, Frontend) dispune de un Dockerfile propriu, optimizat pentru rolul său.

• Orchestrarea realizată în df-engine permite:

  • pornirea și oprirea independentă a containerelor;
  • izolarea responsabilităților fiecărui serviciu;
  • rularea aplicației într-un mod cloud-agnostic (compatibil AWS, Azure sau VPS clasic).

Expunerea aplicației prin HTTP este nesigură, iar configurarea și reînnoirea manuală a certificatelor SSL este predispusă la erori umane și perioade de indisponibilitate.

• Integrarea Nginx ca Reverse Proxy direct în rețeaua Docker pentru gestionarea traficului de intrare.

• Adăugarea unui container Certbot în docker-compose care:

  • obține certificate Let’s Encrypt;
  • rulează scripturi automate (init-cert.sh, renew-certs.sh);
  • partajează volumele de certificate cu Nginx.

• Rezultatul este o soluție de securizare „zero-touch”, cu reînnoire automată a certificatelor HTTPS, fără downtime.

Componentele HTML standard duc la o experiență de utilizare neuniformă, iar stilizarea manuală cu CSS pentru fiecare element crește complexitatea și riscul de bug-uri de afișare.

• Implementarea Angular Material pentru:

  • tabele;
  • dialoguri;
  • formulare și datepickers;
  • asigurarea accesibilității și a unui comportament standardizat.

• Aplicarea unei teme custom (paletă de culori, tipografie) în styles.scss.

• Utilizarea Tailwind CSS pentru:

  • layout-uri responsive rapide;
  • reducerea codului CSS custom;
  • obținerea unui Design System unitar la nivelul aplicației.

Interogările către modelele AI pot avea latență ridicată. Așteptarea răspunsului complet blochează interfața utilizatorului și poate genera timeout-uri pe conexiunile HTTP standard.

• Implementarea protocolului Server-Sent Events (SSE) în ruta de AI-Proxy.

Backend:

• Controller-ul nu returnează un JSON unic.
• Răspunsul este transmis incremental, folosind streaming (yield de bucăți de text pe măsură ce sunt generate).

Frontend:

• Utilizarea EventSource (sau stream reader) pentru:

  • afișarea progresivă a răspunsului;
  • efect vizual de „mașină de scris”.

• Această abordare îmbunătățește semnificativ percepția vitezei și experiența utilizatorului.

Artefactele pe care le-am testat in implementarea mea sunt: endpointurile din controllere (CRUD + flow-uri), mecanismele de autentificare/refresh (JWT + refresh token), autorizarea pe roluri si scoping pe AutoSchoolId, plus persistenta prin EF Core DbContext (in InMemory). La nivel unit am testat componente izolate in fisierele *PositiveTest.cs si NegativeTest.cs, inclusiv serviciile JwtGeneratorToken si JwtRefreshToken si logica de controller in izolare cu Moq. La nivel system end-to-end am testat API-ul complet prin HTTP real in folderul SystemApiTests/ folosind CustomWebApplicationFactory, cu teste dedicate pentru autentificare (AuthControllerSystemTests.cs), autorizare (AuthorizationSystemTests.cs), CRUD (CrudSystemTests_.cs) si flow-uri business (RequestFlowSystemTests.cs, AvailabilityToSessionFormFlowSystemTests.cs). Validarea rezultatelor in toate nivelurile se face prin statusuri HTTP si prin efect observabil in date (verificare in DB InMemory si/sau request de citire ulterior).

In implementarea mea, construirea testelor porneste direct din codul aplicatiei: rutele, metodele si regulile [Authorize] sunt citite din controllere, apoi am construit cazuri pozitive si negative. In SDLC, asta se aplica astfel: in etapa de implementation am scris testele unitare in paralel cu logica (ex: tokenuri si controllere in izolare), iar dupa ce aplicatia a fost rulabila in mediu de test am adaugat testele system end-to-end prin WebApplicationFactory ca sa validez pipeline-ul real (routing, auth, validari). Dupa modificari de cod, suita ruleaza ca regression prin flow-urile cap-coada si matricea de autorizare (in AuthorizationSystemTests.cs si *FlowSystemTests.cs) ca sa detecteze rapid rupturi in contractul endpointurilor sau in regulile de business.

Pentru artefactul “endpoint API + contract HTTP”, am folosit functional testing prin teste system si CRUD lifecycle, implementate in CrudSystemTests_*.cs si testele pe controllere, unde verific explicit secventa CREATE -> LIST -> GET -> UPDATE -> DELETE -> 404 si statusurile (200/201/204/400/404 etc.). Pentru artefactul “securitate endpointuri”, am folosit security testing implementat direct in AuthControllerSystemTests.cs si AuthorizationSystemTests.cs, unde verific 401 fara token, 403 cu rol nepermis, succes cu rol permis si scenarii cross-school pe AutoSchoolId (SchoolAdminB nu poate accesa resurse SchoolA, iar SuperAdmin poate). Pentru artefactul “logica interna tokenuri”, am folosit testare unit determinista in JwtGeneratorTokenPositiveTest/NegativeTest si JwtRefreshTokenPositiveTest/NegativeTest cu scenarii valid/invalid/expirat/config invalid/parametri lipsa, deoarece aceste componente sunt izolabile si defectele trebuie prinse rapid fara pipeline HTTP. Pentru artefactul “flow-uri business”, am folosit testare end-to-end + regresie in RequestFlowSystemTests.cs si AvailabilityToSessionFormFlowSystemTests.cs, deoarece aceste scenarii traverseaza mai multe endpointuri si reguli si doar asa confirm integrarea reala.

Din implementarea mea rezulta ca suita acopera: autentificare (login + refresh cu succes/esec), autorizare pe roluri (matrice pe endpointuri) si izolarea pe AutoSchoolId, CRUD complet pe 9 entitati prin teste dedicate, plus flow-uri business cap-coada (Request flow, Availability -> SessionForm). Observatia cea mai concreta din implementare este ca in testele in care apelez direct actiuni de controller (fara pipeline HTTP), validarea automata nu ruleaza ca in productie, deci pentru scenarii care trebuie sa dea 400 a fost necesar sa setez ModelState explicit in test; in schimb, in testele system end-to-end prin CustomWebApplicationFactory, validarea, 401/403 si restul comportamentelor apar natural deoarece requesturile trec prin pipeline real. O alta observatie este ca repetabilitatea este asigurata prin EF Core InMemory + seed determinist (roluri, scoli, utilizatori, entitati), ceea ce face testele stabile si permite verificarea efectului observabil in date dupa create/update/delete, cu confirmari suplimentare prin requesturi de citire.

In teste verific raspunsul endpointurilor prin codurile de raspuns HTTP si verific comportamentul prin efectul observabil in date adica dupa creare modificare sau stergere se vede schimbarea in DbContext sau printr un request de citire ulterior

Testele sunt grupate in functional testing unde sunt verificate operatiile si regulile de domeniu si in security testing unde este verificat accesul la endpointuri prin autentificare si autorizare

Scenariile pornesc din implementarea reala deoarece rutele metodele si regulile Authorize sunt citite din controllere iar pe baza lor sunt construite cazuri pozitive si negative apoi sunt pregatite date deterministe prin seed si sunt verificate rezultatele prin assert pe raspuns si pe datele din baza in memory

Testele sunt asezate pe nivele astfel incat logica izolata este verificata la nivel unit actiunile controllerului impreuna cu DbContext sunt verificate la nivel integration component iar comportamentul complet al API ului este verificat la nivel system end to end prin HTTP real

La nivel unit sunt verificate componente izolate cu accent pe JWT si refresh prin scenarii valid invalid expirat configuratie invalida si parametri lipsa astfel incat problemele din logica tokenurilor sunt prinse rapid si determinist

La nivel integration component testele apeleaza direct actiunile controllerelor folosind EF Core InMemory cu baza separata pe fiecare test si seed minim iar pentru input invalid care trebuie sa intoarca 400 ModelState este setat explicit in test deoarece in apel direct nu ruleaza automat validarea din pipeline

La nivel system end to end aplicatia este pornita in memorie prin CustomWebApplicationFactory in environment Testing cu baza InMemory si seed determinist iar testele trimit cereri HTTP reale ca sa valideze contractul complet al endpointurilor inclusiv raspunsurile de securitate care apar doar in pipeline real

Pentru entitatile CRUD exista teste cap coada care parcurg creare apoi listare apoi get by id apoi update apoi delete iar la final get by id intoarce 404 ceea ce confirma ca operatiile si persistenta functioneaza corect in sistem

Autentificarea este verificata prin teste de login si refresh token care includ succes si esec iar tokenul obtinut este folosit pe un endpoint protejat iar scenariile negative acopera credentiale gresite refresh invalid refresh expirat si cont blocat cu 423

Autorizarea este verificata printr o matrice pe endpointurile protejate unde fara token rezultatul este 401 iar cu token dar rol nepermis rezultatul este 403 iar cu rol permis apare succes acolo unde scenariul permite iar separat scopingul pe AutoSchoolId este verificat prin scenarii cross school in care SchoolAdminB nu poate accesa resurse create in SchoolA iar SuperAdmin poate

Pentru regresie exista flowuri cap coada care traverseaza mai multe endpointuri si reguli de business precum Request flow si Availability catre SessionForm iar rezultatele sunt verificate prin status si prin datele returnate inclusiv scenarii negative cu rol nepermis id inexistent tranzitie invalida si conflict overlap

Am implementat control de acces pe roluri (RBAC) cu rolurile: SuperAdmin, SchoolAdmin, Instructor, Student. Asta previne accesul neautorizat la endpoint-uri si date atunci cand un utilizator autenticat incearca sa apeleze functionalitati care nu ii sunt permise conform rolului. In curs asta intra la authorization (ce ai voie sa faci) si protejeaza Confidentiality.

Am implementat verificarea de tenant (schoolId) prin SameSchoolHandler + verificari in controllere, astfel incat un utilizator nu poate accesa resursele altei scoli doar schimbind un id in request. Asta trateaza o vulnerabilitate tipica de tip IDOR (Insecure Direct Object Reference) si reduce riscul de “data leaks” intre scoli. In curs, asta se incadreaza la Confidentiality prin control acces la resurse.

Am implementat prevenirea SQL injection folosind EF LINQ si query-uri parametrizate, fara concatenare de input in SQL. Asta trateaza atacul de Injection din curs, unde input-ul poate modifica logica query-ului. Prin parametrizare, input-ul ramine data, nu devine comanda, deci nu poate altera interogarea si nu poate modifica/expune date neautorizat.

RBAC + tenant checks (schoolId) protejeaza si integritatea, pentru ca un utilizator nu poate face update/delete pe resurse care nu apartin rolului sau scolii lui.

Am configurat lockout in Identity: 5 incercari esuate, 10 minute blocare, iar in API am activat lockoutOnFailure ca sa se aplice la login. Cind contul este blocat, API raspunde cu 423 (cont blocat). Asta trateaza brute force si reduce riscul de abuz pe autentificare, exact ca “temporary lockouts” din curs.

Am implementat rate limiting pe endpoint-ul de login (5 req/min pe POST /api/auth) si am adaugat rate limiting si pe endpoint-ul de refresh (/api/auth/refresh). Asta reduce flood-ul pe rutele critice de autentificare si sustine disponibilitatea serviciului, in linie cu apararile din curs pentru DDoS/abuse.

Am implementat doua token-uri separate: JWT access token si refresh token. Refresh token-ul este persistat si validat server-side (se salveaza token-ul si expirarea si se valideaza potrivirea + expirarea la refresh), iar access token-ul are acum durata redusa (60 min → 15–30 min). Durata mai scurta la access token reduce fereastra in care un token compromis poate fi folosit (“changes in duration”), iar refresh token-ul server-side sustine controlul sesiunii (“session storage mechanisms”), exact pe apararile din curs.

Am adaugat logging pentru login fail, astfel incat pot observa incercari repetate esuate si comportamente anormale. Logging-ul este baza pentru detectie, aliniat cu ideea din curs de detectare a pattern-urilor suspecte.

Am configurat CORS strict in backend, inlocuind AllowAnyOrigin cu origin-ul real al frontend-ului. Asta reduce riscul de request-uri cross-origin neautorizate si este masura listata explicit in curs la apararile pentru XSS.

Am implementat validare de input pe toate request-urile relevante, astfel incat datele primite sunt verificate inainte sa fie procesate sau salvate (tipuri corecte, limite/range, formate si constrangeri pentru campuri). Aceasta masura sustine apararea din curs pentru XSS prin “input validation” si reduce riscul ca payload-uri malitioase sa ajunga stocate si apoi afisate in UI.

In aplicatie autentificarea este implementata cu ASP.NET Core Identity, iar parolele sunt gestionate prin mecanismul standard de password hashing. Parola nu este stocata niciodata in clar; la creare/resetare, Identity genereaza un hash (cu salt si parametri de cost) si salveaza doar valoarea in campul PasswordHash, iar la login verifica parola prin rehash + comparare cu hash-ul stocat. Aceasta implementare trateaza riscul de compromitere a parolelor mentionat in curs la autentificarea bazata pe parole si contribuie direct la Confidentiality.

Repository-ul df-engine funcționează ca orchestrator central pentru întreaga infrastructură DriveFlow. Acesta coordonează deployment-ul tuturor microserviciilor prin Docker Compose și oferă o configurare unificată pentru:

• Nginx reverse proxy - rutare trafic către servicii
• Docker Compose - orchestrare containere (API, Accountant, MySQL)
• Git submodules - referințe către celelalte repository-uri
• Scripturi de deploy - automatizare rebuild și restart

Când se face push pe main în oricare repository (API, Accountant sau Engine), workflow-ul respectiv execută scriptul deploy.sh pe VPS, care:

1. Face git pull pentru ultimele modificări
2. Actualizează submodulele dacă e necesar
3. Rebuild-uiește imaginile Docker afectate
4. Restartează containerele fără a șterge volumele (datele MySQL persistă)

Această abordare permite Continuous Deployment - orice modificare pe branch-ul main ajunge automat în producție.

Flux: dev → PR → staging (testare) → PR → main (producție)

Frontend-ul folosește 3 branch-uri pentru a permite:

• Testare completă pe staging înainte de release
• Izolarea dezvoltării active de codul stabil
• Review și QA pe fiecare etapă

Flux: dev → PR cu code review → main (producție)

API-ul folosește 2 branch-uri deoarece:

• Testele unitare (70+) rulează local pe dev
• Code review-ul pe PR asigură calitatea înainte de merge
• Deployment rapid în producție după aprobare

Flux: dev → PR → main (producție)

Microserviciul de facturare folosește aceeași strategie ca API-ul:

• Serviciu mic și focusat, nu necesită staging separat
• Testare locală suficientă datorită scopului limitat
• Deployment rapid pentru fix-uri și îmbunătățiri

Flux: Modificări directe pe main sau PR-uri pentru schimbări majore

Engine-ul menține doar main deoarece:

• Conține doar configurații de infrastructură (Docker, Nginx, scripturi)
• Modificările sunt rare și bine definite
• Testarea se face direct pe VPS (infrastructură identică cu producția)