Retrospettiva: cosa cambierei in una versione reale

Questa lezione appartiene al Modulo 24 — Presentazione, valutazione e retrospettiva.

La differenza tra versione scolastica e versione reale

Il Registro del laboratorio è stato costruito con vincoli precisi: browser, localStorage, nessun server, nessun account. Questi vincoli erano giusti per il contesto scolastico — permettevano di concentrarsi sull’architettura senza distrazioni tecnologiche.

Una versione reale — un sistema che gestisce un vero laboratorio scolastico con 30 studenti, dati sensibili, più utenti contemporanei — avrebbe vincoli diversi. E alcune scelte fatte nel corso andrebbero ripensate.

La retrospettiva non è autocritica — è analisi consapevole. Si distingue tra ciò che funzionava per il contesto scolastico e ciò che andrebbe cambiato per un contesto reale.

Cosa ha funzionato bene (da portare avanti)

Separazione dei quattro livelli

La divisione in domain/, application/, infrastructure/, presentation/ è una scelta architetturale che si scala a sistemi molto più grandi. In una versione reale, i quattro livelli restano — con più file e più casi d’uso, ma la struttura rimane valida.

Archivio come dipendenza esplicita

Il pattern creaRegistraPrestito({ archivioStrumenti, archivioPrestiti }) funziona identicamente con localStorage, con una API REST, con un database. Non va cambiato — va solo collegato a un’infrastruttura diversa.

Errori come codici

STRUMENTO_NON_TROVATO, STRUMENTO_NON_DISPONIBILE — questo pattern funziona anche in produzione. I codici sono stabili, la traduzione in messaggi può cambiare lingua o stile senza toccare il dominio.

Test del dominio senza browser

I test che usano archivi in memoria funzionano identicamente in produzione. È una scelta che scala.

Cosa cambierei in una versione reale

1. Persistenza: da localStorage a un database

Problema: localStorage non è condiviso tra utenti, non è transazionale,
          si perde con la cache, ha un limite di ~5MB.

Versione reale: database relazionale (PostgreSQL, SQLite) con transazioni.

Impatto architetturale: solo infrastructure/ cambia — domain/ e application/ restano.
Il pattern dell'adapter rende questo cambio quasi indolore.

Cosa non cambia: le regole del dominio, i casi d'uso, i test del dominio.

2. Autenticazione e autorizzazioni

Problema: chiunque con accesso al browser può fare qualsiasi operazione.
          Non c'è distinzione tra docente, tecnico e studente.

Versione reale: autenticazione (login con credenziali scolastiche),
               controllo dei ruoli (chi può aprire prestiti, chi può segnalare guasti).

Impatto architetturale: si aggiunge un livello di controllo accessi nell'Application.
Il dominio non cambia — le regole del laboratorio sono le stesse per tutti i ruoli.

3. Coerenza dei dati

Problema: se il tab del browser si chiude dopo aver salvato il prestito
          ma prima di aggiornare lo strumento, i dati diventano incoerenti.
          Non c'è modo di rilevarlo o correggerlo automaticamente.

Versione reale: transazioni atomiche nel database.
               "Salva prestito E aggiorna strumento" diventa una singola operazione atomica.
               Se una parte fallisce, entrambe vengono annullate.

Impatto architetturale: cambia solo l'implementation dell'adapter in infrastructure/.
Il caso d'uso non cambia — già coordina le due operazioni insieme.

4. Storico e audit trail

Problema: il Registro tiene solo lo stato corrente — non sa cosa è successo nel passato.
          Chi ha preso lo strumento la settimana scorsa? Quando è stato segnalato guasto?

Versione reale: eventi immutabili (event log) che registrano ogni operazione con timestamp.
               Il sistema ricostruisce lo stato corrente dall'evento più recente.

Impatto architetturale: si aggiunge un archivio eventi in infrastructure/.
Domain e Application rimangono quasi invariati.

5. Notifiche e aggiornamenti in tempo reale

Problema: se due persone usano il Registro contemporaneamente, non si vedono gli aggiornamenti.
          Persona A presta lo strumento — Persona B vede ancora lo strumento come disponibile.

Versione reale: WebSocket o polling frequente per aggiornare la UI quando i dati cambiano.

Impatto architetturale: cambia solo la Presentation — domain e application non lo sanno.

Cosa era giusto per il contesto scolastico e va mantenuto così

JavaScript modulare senza framework    → giusto per imparare l'architettura senza distrazioni
localStorage come persistenza          → giusto per il laboratorio — nessun server necessario
Un solo utente alla volta             → giusto per il contesto — non c'è concorrenza reale
Test manuali documentati              → giusto come primo approccio ai test

La struttura della retrospettiva

Per ogni scelta fatta nel progetto, questa tabella aiuta a valutarla:

Scelta	Giusto per il corso?	Giusto per produzione?	Cosa cambierei
localStorage	✓	✗	Database con transazioni
Nessuna autenticazione	✓	✗	Login + ruoli
Separazione 4 livelli	✓	✓	Niente
Archivio come dipendenza	✓	✓	Niente
Test del dominio	✓	✓	Aggiungere più casi limite
Errori come codici	✓	✓	Niente

Attività in classe

## Retrospettiva personale

Scelta che rifarei identica e perché:

Scelta che cambierei in una versione reale:
  - Cosa: 
  - Perché non va per la produzione: 
  - Come lo cambierei: 
  - Impatto architetturale (cosa cambierebbe, cosa resterebbe): 

Cosa ho imparato che non sapevo prima di questo corso:

Cosa avrei fatto diversamente sin dall'inizio:

Spiegazione guidata per studiare

Una retrospettiva è onesta quando distingue tra “abbiamo fatto una scelta sbagliata” e “abbiamo fatto la scelta giusta per il contesto”. Nel corso, localStorage era la scelta giusta — era il vincolo del laboratorio. In produzione, sarebbe sbagliata. Questa distinzione è importante.

Il punto centrale è: le scelte architetturali si valutano rispetto al contesto, non in assoluto. Un’architettura perfetta per un laboratorio scolastico con 10 strumenti può essere sbagliata per un magazzino con 10.000 articoli. Capire quando una scelta scala e quando no è la competenza che si porta via dal corso.

Il rischio tipico è concludere la retrospettiva con “abbiamo fatto tutto giusto” o “abbiamo fatto tutto sbagliato”. Entrambe le posizioni sono false. Ogni progetto ha scelte giuste e scelte che andrebbero riviste — il valore sta nel saperle distinguere.

Passo per passo nel progetto

1. Elenca le cinque scelte architetturali più importanti del tuo Registro.
2. Per ognuna: funzionava per il contesto scolastico?
3. Per ognuna: funzionerebbe per un sistema reale con 100 studenti?
4. Identifica la scelta più importante da cambiare in una versione reale.
5. Descrivi l’impatto architetturale: cosa cambierebbe, cosa resterebbe.

Esempio da leggere lentamente

Scelta: localStorage come unica persistenza.

Giusto per il corso: sì. Nessun server da configurare, zero dipendenze esterne,
dati che persistono tra sessioni. Perfetto per imparare l'architettura senza
distrazioni operative.

Non giusto per la produzione: i dati sono per-browser, non condivisibili tra utenti,
non backup-abili automaticamente, soggetti a perdita con la cache. Un laboratorio
reale con 3 tecnici ha bisogno che tutti vedano gli stessi dati.

Cosa cambierei: sostituirei creaArchivioStrumentiLocalStorage con
creaArchivioStrumentiDatabase. Il caso d'uso registraPrestito non cambierebbe —
riceve già l'archivio come dipendenza.

Impatto architetturale: solo infrastructure/ cambia. Tutto il resto rimane identico.
Questa è la prova che la separazione dei livelli funziona.

Prova di comprensione

• Quale scelta del corso era giusta per il contesto scolastico ma non per la produzione?
• Quale scelta invece scala bene anche a sistemi reali?
• Se dovessi riprendere questo progetto tra un anno, quale sarebbe la prima cosa da cambiare?

Errori da evitare

• dire “tutto era sbagliato” — alcune scelte erano deliberatamente semplificate per il contesto;
• dire “tutto era giusto” — ogni progetto ha margini di miglioramento;
• identificare problemi senza ragionare sull’impatto architetturale della correzione;
• non distinguere tra “limite del contesto scolastico” e “errore di progettazione”.

Prodotto da consegnare

Può essere:

• la scheda retrospettiva compilata con almeno una scelta da cambiare e relativo impatto;
• la tabella delle scelte con valutazione per il corso e per la produzione;
• un paragrafo nel README che descrive i limiti noti e cosa cambierebbe in una versione reale.

Checklist di chiusura

• Ho identificato almeno tre scelte architetturali del mio Registro
• Per ognuna ho valutato: funzionava per il contesto scolastico?
• Per ognuna ho valutato: funzionerebbe per la produzione?
• Ho descritto l’impatto architetturale di almeno una modifica
• Ho distinto tra “limite deliberato” e “errore di progettazione”

Domande per la revisione

• Quale scelta hai trovato più difficile da valutare? Perché?
• L’impatto architetturale che hai descritto è realistico? Tocchi solo un livello o tutti?
• Se riprendessi questo progetto domani, da dove inizieresti?

Risultato atteso

Alla fine lo studente deve saper dire:

Nel mio Registro, la scelta [X] era giusta per il contesto scolastico perché [motivo].
In una versione reale, la cambierei con [Y] perché [motivo].
L'impatto architetturale sarebbe: [cosa cambia, cosa resta].
La scelta [Z] invece scala bene anche per la produzione e non la cambierei.

Se questa spiegazione non è possibile, la lezione non è ancora davvero conclusa.