Servizi di piattaforma (Tier 2 — Applicazione)
task-service
Possiede: il catalogo delle challenge e il ciclo di vita delle assegnazioni. È il cuore del modello self-service.
Responsabilità:
- Catalogo challenge: definizione, tier di complessità, prezzo, microservizio target, bundle di contesto, criteri di accettazione
- Claim / release / scadenza delle assegnazioni
- Emissione di grant di accesso temporanei: claimare la challenge X concede visibilità sul microservizio X, con una scadenza. Consegna, abbandono o scadenza la revocano.
- Limite su claim attivi concorrenti per collaboratore
Note di design:
- L'accesso è derivato dal claim, mai assegnato staticamente. Questo è ciò che rende "scegli il task che vuoi, quando vuoi" compatibile con lo scoping.
- Il catalogo stesso è information disclosure: elencare ogni microservizio dice a un collaboratore la forma del sistema. Filtra il catalogo in base a cosa il collaboratore è eligibile a vedere.
- Senza un cap sui claim concorrenti, il claiming ripetuto ricostruisce la mappa completa.
validation-service
Possiede: la API pubblica per eseguire i check. Accetta e mette in coda; non esegue.
Responsabilità:
- Esporre
check(solo validazione, nessun side effect) esubmit(validazione → build → commit) - Validare la richiesta rispetto all'ACL del chiamante prima di metterla in coda
- Restituire un job handle; stream di status e log
- Persistere l'esito rispetto all'hash del contenuto
Note di design:
- Due modalità da un unico code path. Se l'unico modo di eseguire i check è pubblicare, i gate diventano un esame invece di uno strumento, e i collaboratori smettono di usarli.
- L'API accetta structured intent (challenge id, snapshot hash), mai comandi free-form da eseguire.
job-runner
Possiede: l'esecuzione asincrona della pipeline di validazione.
Responsabilità:
- Consumare la coda (BullMQ) ed eseguire la pipeline CLI come subprocess
- Emettere progresso e log per-step per lo streaming
- Applicare timeout e cleanup
- Isolare le esecuzioni concorrenti l'una dall'altra
Un'esecuzione completa richiede minuti. Un pulsante che gira per quattro minuti senza feedback viene premuto di nuovo — quindi progresso per step, e idempotenza sulla job key.
profile-service
Possiede: il registro dei contributi e tutto ciò che ne deriva.
Responsabilità:
- Cronologia immutabile dei contributi per collaboratore
- Calcolo del livello rispetto a criteri pubblicati
- Pagine di profilo pubbliche (opt-in, pseudonimo supportato)
- Generazione di certificati PDF con QR code e credential ID
- Endpoint di verifica: valido / superato / revocato
Note di design:
- Due superfici con esposizione diversa: un'API interna autenticata e una pubblica non autenticata. Vale la pena isolare per questa sola ragione.
- Adotta lo schema dati Open Badges 3.0 dall'inizio (achievement, criteria, evidence, issuer). Rimanda la macchina crittografica — firme, chiavi, DID — fino a quando il volume lo giustifica. Struttura ora, crypto dopo.
- Costruisci la revoca dal primo giorno; non può essere aggiunta credibilmente in seguito.
notification-service
Possiede: messaggi in uscita.
Responsabilità: esiti della pipeline, nuove challenge che corrispondono a un profilo, cambiamenti di livello, avvisi di scadenza dei claim. Preferenze del canale per utente.
artifact-store
Possiede: oggetti immutabili di grandi dimensioni — log di build, report di validazione, snapshot.
Responsabilità: storage content-addressed con chiave per hash, policy di retention, URL firmati per il download.
Questi crescono velocemente e non appartengono al database relazionale.