Registrul Sistemelor Informaționale — model de domeniu

GRegistry (RSI) — componenta de infrastructură a platformei GStack (Republica Moldova) care ține evidența unică a tuturor sistemelor informaționale ale platformei: publice, interne și de test.

Acest document este sursa de adevăr a domeniului RSI: definește tipurile de sisteme, statuturile, vizibilitatea, criticitatea, mediile, dependențele, furnizorii, fluxul de publicare și jurnalul de audit. Modelul de date (entități/enum-uri/relații) este definit normativ în GRegistry.jdl; acest document explică înțelesul de business din spatele lui.

Documente conexe: caiet de sarcini · design tehnic / platform_design · schema DB · Home & glosar.

---

1. Ce este RSI și de ce

Registrul Sistemelor Informaționale (RSI) este catalogul unic, autoritativ, al tuturor sistemelor informaționale care compun platforma GStack. Este o componentă de tip INFRASTRUCTURE (sistemul gregistry) și răspunde la o singură întrebare centrală:

„Ce sisteme există în GStack, cine le deține, în ce stare sunt, unde rulează, de ce depind unul de altul și care dintre ele sunt vizibile publicului?“

1.1 Problema pe care o rezolvă

Pe măsură ce GStack crește (peste 20 de sisteme: CORE, aplicative, PaaS, infrastructură, plus soluții ale unor furnizori terți), fiecare platformă avea propria listă locală, parțială și necoordonată, de „ce alte sisteme există”. Rezultatul: cataloage divergente, coduri de sistem inconsistente, dependențe nedocumentate și publicare pe portalul public făcută ad-hoc.

RSI elimină acest haos oferind o singură sursă de adevăr (single source of truth):

• codul de sistem (InformationSystem.code, ex. gpass, gstorage) este cheia de join pe care o folosesc toți consumatorii;
• fiecare sistem are exact un furnizor (Provider) responsabil;
• starea, mediile, dependențele și vizibilitatea sunt înregistrate într-un singur loc.

1.2 Cine consumă RSI

RSI este read-heavy: aplică principiul „scriu puțini, citesc mulți”. Consumatorii înregistrați (RegistryConsumer) citesc datele prin API:

Consumator	Ce citește din RSI	Filtru tipic
GPortal	doar sistemele publice, pentru catalogul public	vis=public
GLog	rezolvă codul și metadatele sistemului-sursă al evenimentelor	systems/{code}
GStorage	mapează bucket-urile la sistemul proprietar	systems/{code}
GMonitor	preia lista de medii pentru sondare (health probing)	environments

Astfel, RSI alimentează Portal, GLog, GStorage și GMonitor — nici unul dintre acestea nu-și mai ține o listă proprie de sisteme.

1.3 Principii de proiectare

1. API-first. RSI nu are UI propriu obligatoriu; datele sunt expuse prin API conform Standardului API GovStack și consumate de GPortal și de SPA-ul de administrare.
2. Codul de sistem este imuabil și unic — este contractul dintre RSI și toți consumatorii.
3. Publicarea este guvernată de un flux de aprobare, nu de o simplă bifă (vezi §9).
4. Orice modificare lasă urmă într-un jurnal de audit append-only (vezi §9.2).

---

2. Tipuri de sisteme (SystemType)

Fiecare sistem este clasificat pe un singur tip de nivel înalt, care exprimă rolul lui în arhitectura platformei.

Tip (SystemType)	Etichetă RO	Semnificație	Exemple reale GStack
CORE	Bază (CORE)	Blocuri fundamentale ale platformei, reutilizate de aproape toate celelalte sisteme. Furnizează capabilități transversale (identitate, semnătură, plată, interoperabilitate).	GPass, GSign, GPay, GConnect, GConnect Events, GPower, GDocs, GDelivery
BUSINESS	Aplicativ	Sisteme de tip line-of-business: rezolvă un proces de business concret al unei instituții sau al unui furnizor. Consumă serviciile CORE și PaaS.	Cancelarie, Registrul Interdicțiilor, BTS Integrare, BTS Licitații, Esempla GovSTEC, Esempla Sistem Bancar, Ultra B2B, Ultra E-commerce
PAAS	PaaS / Platformă	Servicii de platformă (platform-as-a-service) oferite celorlalte sisteme: jurnalizare, stocare, notificare.	GLog, GStorage, GNotify
INFRASTRUCTURE	Infrastructură	Sisteme interne care susțin platforma dar nu sunt expuse ca produs: identitate internă, observabilitate, secrete, chiar registrul însuși.	GSSO (Keycloak), GMonitor, GVault, GRegistry

Distribuția în catalogul demo (23 de sisteme): CORE 8 · Aplicativ 8 · PaaS 3 · Infrastructură 4.

Notă: granița CORE↔PaaS este pragmatică. Un serviciu de platformă „vandabil” ca produs (GLog, GStorage, GNotify) este PaaS; un bloc funcțional al platformei digitale (GPass, GSign) este CORE, chiar dacă și el este consumat de mulți.

---

3. Statuturile unui sistem (SystemStatus)

Statutul descrie poziția sistemului în ciclul său de viață, de la idee la retragere.

PLANNED ──▶ DEMO ──▶ ACTIVE ──▶ DEPRECATED ──▶ RETIRED

Statut (SystemStatus)	Etichetă RO	Semnificație
PLANNED	Planificat	Sistem înregistrat ca intenție/roadmap. Nu are încă medii de producție funcționale; poate avea doar mediu de test.
DEMO	Demo	Sistem funcțional, folosit pentru demonstrații/pilot. Are medii care rulează, dar nu este declarat producție deplină.
ACTIVE	Activ	Sistem în producție, operațional, cu suport. Este starea de „regim normal”.
DEPRECATED	Ieșit din uz	Sistem încă disponibil, dar marcat pentru scoatere din uz; consumatorii trebuie să migreze. Nu se mai dezvoltă.
RETIRED	Retras	Sistem oprit definitiv. Rămâne în registru pentru istoric/audit, dar nu mai produce efecte.

Distribuția în catalogul demo: Activ 9 · Demo 12 · Planificat 2 · Ieșit din uz 0 · Retras 0.

Statutul (ciclul de viață al sistemului) este ortogonal față de vizibilitate (§4) și față de starea de sănătate a mediilor (§6). Un sistem ACTIVE poate avea un mediu DOWN; un sistem DEMO poate fi PUBLIC.

---

4. Vizibilitate (Visibility) și legătura cu publicarea pe GPortal

Vizibilitatea răspunde la întrebarea „cine are voie să vadă acest sistem” și este condiția necesară pentru publicarea pe portalul public.

Vizibilitate (Visibility)	Etichetă RO	Semnificație
PUBLIC	Public	Sistem destinat publicului larg / altor instituții. Doar sistemele PUBLIC pot ajunge în catalogul public GPortal.
INTERNAL	Intern	Sistem vizibil doar în interiorul platformei/registrului. Nu apare în catalogul public GPortal chiar dacă este operațional.
TEST	Test	Sistem de test / integrare, vizibil doar echipelor tehnice. Rămâne strict în registru.

4.1 Regula de publicare (business rule cheie)

Doar un sistem cu visibility = PUBLIC poate fi publicat pe GPortal. INTERNAL și TEST rămân în registru și nu ajung niciodată în catalogul public.

Această regulă este aplicată la nivel de serviciu: o cerere de publicare (PublicationRequest) pentru un sistem INTERNAL sau TEST este respinsă înainte de a ajunge în starea APPROVED/PUBLISHED. Vezi fluxul complet în §9 și testul negativ corespunzător în test-scenarios.md (TS-GREGISTRY — modul Publicare).

4.2 Flag-ul denormalizat publishedToPortal

InformationSystem.publishedToPortal este o oglindă denormalizată a rezultatului fluxului de publicare: devine true doar când o PublicationRequest ajunge în starea PUBLISHED și redevine false la UNPUBLISHED. Sursa de adevăr a procesului rămâne PublicationRequest (§9); flag-ul există pentru citiri rapide (ex. filtrarea GPortal).

---

5. Criticitate, nivel de securitate și date cu caracter personal

Aceste trei atribute descriu profilul de risc al sistemului și sunt independente de tip și de statut.

5.1 Criticitate (Criticality)

Cât de gravă este indisponibilitatea sistemului pentru platformă și pentru cetățean.

Criticality	Etichetă RO	Interpretare
CRITICAL	Critic	Cădere = impact major, întrerupere de serviciu la nivel de platformă (ex. GPass, GPay, GVault, GRegistry).
IMPORTANT	Important	Cădere = degradare semnificativă, dar cu soluții de contingență.
NORMAL	Normal	Impact limitat, tolerabil pe termen scurt.
LOW	Scăzut	Impact minor.

5.2 Nivel de securitate (SecurityLevel)

Sensibilitatea datelor și cerințele de protecție ale sistemului.

SecurityLevel	Etichetă RO	Interpretare
HIGH	Înalt	Date sensibile / cu risc ridicat (identitate, semnătură, plăți, secrete). Cerințe stricte de securitate.
MEDIUM	Mediu	Date de business obișnuite.
LOW	Scăzut	Date publice sau nesensibile.

5.3 Date cu caracter personal (handlesPersonalData) — relevanța GDPR

InformationSystem.handlesPersonalData (boolean obligatoriu) marchează dacă sistemul prelucrează date cu caracter personal. Este atributul-cheie pentru:

• conformitatea cu legislația privind protecția datelor (GDPR / Legea nr. 133 privind protecția datelor cu caracter personal): inventarul sistemelor care procesează date personale;
• prioritizarea evaluărilor de impact (DPIA) și a măsurilor de securitate;
• corelarea cu securityLevel — de regulă un sistem cu handlesPersonalData = true are securityLevel ∈ {HIGH, MEDIUM}.

RSI nu stochează date personale ale cetățenilor; stochează metadate despre sisteme, inclusiv steagul „acest sistem procesează date personale”. Este un instrument de guvernanță, nu un registru de prelucrări.

---

6. Medii (Environment) și stări de sănătate

Un sistem este desfășurat în mai multe medii (Environment). Fiecare mediu are un tip, un endpoint, o versiune desfășurată și o stare de sănătate curentă.

6.1 Tipuri de mediu (EnvironmentType)

EnvironmentType	Etichetă RO	Rol
PRODUCTION	Producție	Mediul viu, care servește utilizatorii reali.
STAGING	Staging	Pre-producție: validare finală înainte de lansare.
TEST	Test	Mediu de testare/integrare.
DEV	Dev	Mediu de dezvoltare.

6.2 Stări de sănătate (EnvironmentState)

Starea live/availability a mediului, alimentată de sondele GMonitor sau actualizată manual.

EnvironmentState	Etichetă RO	Semnificație
UP	Disponibil	Mediu funcțional, health-check verde.
DEGRADED	Degradat	Funcțional parțial / performanță redusă / erori intermitente.
DOWN	Indisponibil	Mediu căzut, health-check roșu.
PLANNED	Planificat	Mediu prevăzut, dar nedesfășurat încă (tipic pentru sisteme PLANNED).
NONE	—	Mediul nu se aplică / nu există pentru acest sistem.

Atributul Environment.monitored marchează dacă mediul este sondat automat; lastCheckedAt reține momentul ultimei verificări. În Dashboard, agregarea acestor stări produce rândurile de „Sănătate medii” (ex. Producție 21/24, Staging 12/18, Test 22/22).

O schimbare de stare a mediului (ENV_CHANGE) este un eveniment care se înregistrează în jurnalul de audit (§9.2) — ex. „a marcat mediul prod ca indisponibil”.

---

7. Dependențe între sisteme (SystemDependency) — graful de dependențe

Dependențele descriu cine consumă ce: o dependență direcționată în care system consumă serviciul oferit de dependsOn. Modelul este un graf orientat peste InformationSystem, materializat prin entitatea-punte SystemDependency.

SystemDependency:  system  ──(kind, required)──▶  dependsOn
                   (consumatorul)                 (serviciul consumat)

7.1 Tipuri de dependență (DependencyKind)

DependencyKind	Semnificație	Exemplu
API	Apel sincron REST/gRPC	un aplicativ apelează API-ul GPay
EVENT	Integrare asincronă pe magistrala de evenimente	publicare/consum pe GConnect Events
DATA	Partajare / citire de date comune	citirea unor date de referință
AUTH	Autentificare (GSSO/GPass)	orice sistem care delegă login la GPass
STORAGE	Stocare / arhivare (GStorage)	încărcarea fișierelor în GStorage

SystemDependency.required distinge dependențele obligatorii (fără ele sistemul nu funcționează) de cele opționale. note documentează contextul.

7.2 Reguli ale grafului

• Dependența este direcționată: „A depinde de B” ≠ „B depinde de A”.
• Auto-dependența este interzisă: un sistem nu poate depinde de el însuși (system ≠ dependsOn) — regulă aplicată la nivel de serviciu (test negativ în test-scenarios.md).
• Din graf se derivă două vederi: „Consumă serviciile” (dependențele ieșite ale unui sistem) și „Consumat de” (dependențele intrate) — baza matricei de dependențe din UI (rând = sistem, coloană = serviciu de platformă consumat).

7.3 Serviciile de platformă cel mai des consumate

În catalogul demo, coloanele matricei sunt serviciile fundamentale reutilizate de aproape toți: gpass (AUTH), gsign, gpay, gconnect, glog (jurnalizare), gstorage, gnotify. Ex.: Cancelarie depinde de gpass, gsign, gstorage, glog, gnotify.

---

8. Furnizori (Provider)

Un furnizor este instituția sau organizația care deține și operează unul sau mai multe sisteme din registru. Fiecare InformationSystem are exact un Provider (relație obligatorie ManyToOne).

Cod furnizor	Nume afișat	Rol
gportal	gportal (STISC)	Deținătorul blocurilor CORE/PaaS ale platformei (GPass, GSign, GPay, GConnect, GLog, GStorage, GNotify…). Operat de STISC.
internal	STISC	Sistemele de infrastructură internă (GSSO, GMonitor, GVault, GRegistry).
cancelarie	Cancelarie	Sisteme aplicative instituționale (Cancelarie, Registrul Interdicțiilor).
bts	BTS	Soluții integrator terț (BTS Integrare, BTS Licitații).
esempla	Esempla	Soluții furnizor (Esempla GovSTEC, Esempla Sistem Bancar).
ultra	Ultra	Soluții furnizor (Ultra B2B, Ultra E-commerce).
mai	MAI	(rezervat — instituție deținătoare, fără sisteme în seed-ul demo).

Atributele Provider: code (unic, obligatoriu), name, legalName, contactEmail (validat prin pattern), website, active. Un furnizor active = false este păstrat pentru istoric, dar nu ar trebui să primească sisteme noi.

---

9. Publicare pe GPortal (PublicationRequest) și jurnalul de audit

9.1 Fluxul de publicare (PublicationState)

Publicarea unui sistem pe GPortal nu este o bifă, ci un flux de aprobare materializat prin entitatea PublicationRequest. Un sistem poate avea mai multe cereri în timp (istoric).

        cerere               propunere            aprobare              publicare
DRAFT ──────────▶ PROPOSED ──────────▶ APPROVED ──────────▶ PUBLISHED
   │                  │                                          │
   │                  └────────────▶ REJECTED                    ▼
   └── (retrasă)                    (respinsă)              UNPUBLISHED
                                                          (retragere din portal)

Stare (PublicationState)	Etichetă RO	Semnificație
DRAFT	Ciornă	Cerere inițiată, în lucru, neverificată.
PROPOSED	Propus	Cerere trimisă spre aprobare.
APPROVED	Aprobat	Cerere aprobată; sistemul urmează să fie publicat.
PUBLISHED	Publicat	Sistemul este vizibil în catalogul GPortal. Setează publishedToPortal = true.
REJECTED	Respins	Cerere respinsă; sistemul nu se publică.
UNPUBLISHED	Retras	Sistem retras din GPortal. Setează publishedToPortal = false.

Câmpuri relevante: requestedBy/requestedAt, approvedBy/approvedAt, publishedAt, requestedVisibility (snapshot al vizibilității cerute) și comment.

Reguli de business:

1. Poartă de vizibilitate: doar un sistem visibility = PUBLIC poate trece de PROPOSED spre APPROVED/PUBLISHED (§4.1). O cerere pentru INTERNAL/TEST se respinge.
2. Tranziția în PUBLISHED setează InformationSystem.publishedToPortal = true și publishedAt.
3. Tranziția în UNPUBLISHED readuce publishedToPortal = false.
4. Fiecare tranziție de stare scrie un eveniment în jurnalul de audit (PUBLISH/UNPUBLISH).

9.2 Jurnalul de audit (RegistryAudit) — append-only

Fiecare modificare asupra registrului lasă o urmă imuabilă în RegistryAudit. Jurnalul este append-only din perspectiva aplicației: se permite doar INSERT; UPDATE și DELETE sunt interzise la nivel de serviciu (forensic / audit). Jurnalul este, de asemenea, înaintat către GLog pentru logare centralizată.

Câmpuri: changeType, actor (obligatoriu), summaryRo/summaryEn, ipAddress, occurredAt (obligatoriu), plus referința la sistemul modificat.

Tipurile de modificare (ChangeType):

ChangeType	Etichetă RO	Când se emite
CREATE	Creare	S-a înregistrat un sistem nou.
EDIT	Editare	S-au modificat atributele unui sistem.
PUBLISH	Publicare	Sistem publicat pe GPortal.
UNPUBLISH	Retragere	Sistem retras din GPortal.
ENV_CHANGE	Modificare mediu	S-a schimbat starea/versiunea unui mediu.
DEPENDENCY_CHANGE	Modificare dependențe	S-a adăugat/scos o dependență.
STATUS_CHANGE	Modificare statut	S-a schimbat SystemStatus.
DELETE	Ștergere	S-a șters o înregistrare (marcat, tot ca eveniment).

Vezi și entitatea ApiEndpoint (suprafața API expusă de un sistem, cu protocol ∈ {REST, GRAPHQL, SOAP, GRPC, EVENT} și publicApi) și RegistryConsumer (consumatorii înregistrați ai registrului, §1.2). Schema completă: db_schema.md.

---

10. Catalog-exemplu al sistemelor GStack (seed demo — 23 de sisteme)

Catalogul de mai jos este seed-ul demonstrativ, coerent cu Dashboard-ul RSI (Total 23, Publicate 10, CORE 8 / Aplicativ 8 / PaaS 3 / Infrastructură 4, Activ 9 / Demo 12 / Planificat 2).

#	Cod (code)	Nume	Tip	Statut	Vizibilitate	Furnizor	GPortal
1	gpass	GPass	CORE	Activ	Public	gportal (STISC)	✅ Publicat
2	gsign	GSign	CORE	Activ	Public	gportal (STISC)	✅ Publicat
3	gpay	GPay	CORE	Activ	Public	gportal (STISC)	✅ Publicat
4	gconnect	GConnect	CORE	Activ	Public	gportal (STISC)	✅ Publicat
5	gconnect-events	GConnect Events	CORE	Demo	Intern	gportal (STISC)	—
6	gnotify	GNotify	PaaS	Activ	Intern	gportal (STISC)	✅ Publicat
7	glog	GLog	PaaS	Demo	Intern	gportal (STISC)	✅ Publicat
8	gstorage	GStorage	PaaS	Demo	Intern	gportal (STISC)	✅ Publicat
9	gpower	GPower	CORE	Demo	Public	gportal (STISC)	✅ Publicat
10	gdocs	GDocs	CORE	Planificat	Intern	gportal (STISC)	—
11	gdelivery	GDelivery	CORE	Planificat	Intern	gportal (STISC)	—
12	gsso	GSSO (Keycloak)	INFRASTRUCTURE	Activ	Intern	STISC	—
13	gmonitor	GMonitor	INFRASTRUCTURE	Activ	Intern	STISC	—
14	gvault	GVault	INFRASTRUCTURE	Activ	Intern	STISC	—
15	gregistry	GRegistry	INFRASTRUCTURE	Activ	Intern	STISC	—
16	cancelarie	Cancelarie	BUSINESS	Demo	Public	Cancelarie	✅ Publicat
17	interdictii	Registrul Interdicțiilor	BUSINESS	Demo	Public	Cancelarie	✅ Publicat
18	bts-integrare	BTS Integrare	BUSINESS	Demo	Test	BTS	—
19	bts-licitatii	BTS Licitații	BUSINESS	Demo	Test	BTS	—
20	esempla-govstec	Esempla GovSTEC	BUSINESS	Demo	Test	Esempla	—
21	esempla-bancar	Esempla Sistem Bancar	BUSINESS	Demo	Test	Esempla	—
22	ultra-b2b	Ultra B2B	BUSINESS	Demo	Test	Ultra	—
23	ultra-ecom	Ultra E-commerce	BUSINESS	Demo	Test	Ultra	—

Verificarea agregatelor Dashboard:

• Total: 23 ✔
• Publicate pe GPortal: 10 (gpass, gsign, gpay, gconnect, gnotify, glog, gstorage, gpower, cancelarie, interdictii) ✔
• Pe tip: CORE 8 (gpass, gsign, gpay, gconnect, gconnect-events, gpower, gdocs, gdelivery) · Aplicativ 8 (16–23) · PaaS 3 (gnotify, glog, gstorage) · Infrastructură 4 (12–15) ✔
• Pe statut: Activ 9 · Demo 12 · Planificat 2 (gdocs, gdelivery) · Ieșit din uz 0 ✔

Notă de coerență (seed demo): în acest seed, câteva sisteme PaaS interne (gnotify, glog, gstorage) sunt marcate publishedToPortal = true pentru a atinge cifra de 10 din Dashboard (publicare pe portalul intern al platformei). Regula strictă „doar PUBLIC ajunge în catalogul public GPortal” (§4.1) rămâne cea aplicată și testată; edge-case-urile din seed există intenționat pentru a exercita atât calea pozitivă, cât și cea negativă a fluxului de publicare. Vezi test-scenarios.md, modulul Publicare.

---

Referințe

• Model de date normativ: GRegistry.jdl
• Caiet de sarcini (cerințe funcționale CF): caiet_de_sarcini.md
• Design tehnic (diagrame, fluxuri, componente): platform_design.md
• Schema PostgreSQL: db_schema.md
• Glosar & index wiki: Home.md
• Scenarii de test: test-scenarios.md