Arhitectura sistemului

cortina-north-asoc este construit intenționat ca un monolit modular cu granițe interne clare, nu ca un sistem distribuit de microservicii.

• Produsul este încă centrat pe un singur domeniu de business coerent: administrarea contractelor pentru asociație.
• Echipa a investit deja în descoperirea modulelor, feature slices, tipuri de domeniu puternice și biblioteci interne reutilizabile.
• Runtime-ul beneficiază de autentificare centralizată, persistență, integrare Blob și orchestrare.

Principalele puncte de presiune arhitecturală sunt consolidarea securității, claritatea operațională și numărul tot mai mare de responsabilități din modulul Documents. Poziția actuală de deployment este și ea mai puternică decât un stack web plus API generic, deoarece frontendul este singurul punct public de intrare, backendul nu are ingress extern, iar Key Vault, Blob Storage și Azure SQL rămân pe private endpoints.

Frontend

Frontendul este un host Blazor Server cu startup subțire, acces către API concentrat în clienți locali pe feature, provisionare de utilizator executată în fluxul OpenID Connect de autentificare și controale de securitate la nivel de host, precum CSP, security headers și colectarea rapoartelor.

Backend și module

Hostul API compune autentificarea, autorizarea, forwarded headers, rate limiting, corelarea cererilor, antiforgery, exception handling, persistența auditului la eșec și maparea endpointurilor o singură dată. Comportamentul de business rămâne în modulele Users, Documents și TokenCache.

Infrastructură

Infrastructura centralizează EF Core, registrele de repository, Azure Blob pentru documente, integrarea Microsoft Graph și seed-urile pentru proprietățile canonice. Configurația este sursată din Key Vault, bloburile pentru documente și data protection sunt separate, iar managed identities sunt folosite pentru acces cu privilegii minime.

Model de domeniu

Decizia cheie de domeniu este folosirea agregatului ContractCollection pentru utilizatorul curent. Astfel, verificările de ownership rămân aproape de granița datelor, iar contractele, proprietarii, proprietățile și documentele sunt subordonate unui singur agregat deținut de utilizator.

Identitate și trust boundaries

Soluția folosește deliberat două modele de încredere: API-urile pentru utilizatori se bazează pe JWT bearer tokens și politica ApiAccess, în timp ce API-ul intern de token cache se bazează încă pe o cheie API statică partajată. Ingressul privat reduce expunerea, dar identitatea apelantului pe acel traseu intern rămâne mai slabă decât restul modelului bazat pe Entra.

Modelul de configurație

AppHost proiectează valorile de mediu în procesele frontend și backend. Asta păstrează orchestrarea locală reproductibilă și evită logica duplicată de transformare a secretelor.

Modelul de ownership al datelor

Backendul rezolvă constant Azure user id-ul autentificat, îl mapează la utilizatorul intern și încarcă datele contractuale deținute de acel utilizator înainte de operațiile de citire sau scriere. Aceasta este una dintre cele mai solide alegeri de design din cod.

Scalabilitate

Feature-urile backend sunt stateless, iar SQL plus Blob Storage sunt folosite corect, dar frontendul Blazor Server va deveni primul blocaj de scalare pe măsură ce cresc sesiunile concurente și conexiunile SignalR.

Performanță

Stocarea documentelor în Blob, datele canonice pentru lookup și traficul separat de token cache sunt alegeri bune. Principalul punct de urmărit este orchestrarea tot mai „chatty” din pagina Contracts pe măsură ce crește volumul datelor.

Securitate

Stackul are o bază puternică: autorizare scoped, fără secrete hardcodate, configurație prin Key Vault, private endpoints, throttling dedicat pentru token cache, correlation IDs, audit append-only, CSP și validare allow-list pentru metadatele documentelor. Golurile principale rămase sunt controlul egressului, validarea conținutului documentelor și o identitate mai puternică pentru traseele interne privilegiate.

Fiabilitate și mentenabilitate

Startupul subțire, feature slices, bibliotecile interne partajate și constantele de rută ajută mentenabilitatea. Cel mai important risc de fiabilitate este comportamentul cu efecte multiple în provisioning, iar principala presiune de mentenabilitate este modulul Documents, care continuă să crească.

Operabilitate

Metricile pe workflow, colectarea rapoartelor CSP, correlation IDs și persistența auditului au îmbunătățit vizibil observabilitatea. Suportul încă depinde de corelarea mai multor semnale, iar outbound access nelimitat menține capacitatea de izolare dependentă de detecție rapidă.

Păstrați arhitectura de monolit modular. Nu separați serviciile încă.

1. Adăugați vizibilitate pentru egress și reduceți progresiv accesul outbound la destinațiile strict necesare.
2. Adăugați validare a conținutului documentelor și malware scanning sau carantină înainte ca fișierele încărcate să devină general accesibile.
3. Decideți dacă frontendul public rămâne pe ingress direct în Container Apps sau se mută în spatele unui strat dedicat de edge protection, păstrând consolidarea CSP.
4. Înlocuiți cheia API partajată pentru token cache cu un model mai puternic de identitate service-to-service când costul operațional este justificat.
5. Documentați și refactorizați gradual modulul Documents în sub-capabilități mai clare.
6. Reevaluați extracția de servicii doar dacă granițele de echipă, independența deploymentului sau cerințele de throughput se schimbă semnificativ.