Micro-sfida: cambia archivio senza modificare il caso d’uso

Questa micro-sfida chiude il modulo su Infrastructure.

Il prodotto da mostrare è molto preciso:

Cambia archivio senza modificare il caso d'uso.

Se devi toccare il caso d’uso, hai trovato un confine ancora debole.

Obiettivo

Verificare che:

• gli archivi rispettino lo stesso contratto;
• la scelta dell’archivio sia nel punto di composizione;
• localStorage resti in Infrastructure;
• i casi d’uso restino stabili.

Prodotto da consegnare

Qui “consegnare” significa mostrare al docente o al gruppo un risultato verificabile: un file modificato, una scheda compilata, un test, una demo o una nota tecnica.

Scegli un caso d’uso:

• RegistraStrumento;
• RegistraPrestito;
• ChiudiPrestito.

Poi sostituisci l’archivio:

da memoria a localStorage

oppure:

da localStorage a memoria

Non modificare il file del caso d’uso.

Vincoli

Durante la sfida:

• non modificare src/application/registraStrumento.js;
• non modificare src/application/registraPrestito.js;
• non modificare src/application/chiudiPrestito.js;
• puoi modificare main.js;
• puoi modificare file in infrastructure;
• puoi aggiungere adapter;
• puoi aggiornare README o scheda di verifica.

Passo 1: identifica il contratto

Scrivi:

## Contratto usato

Caso d'uso:

Metodi richiesti:
- salva
- trovaPerId
- tutti

Se il caso d’uso usa metodi non documentati, annotalo.

Passo 2: scegli l’archivio sostitutivo

Esempio:

const archivioStrumenti = creaArchivioStrumentiLocalStorage();

al posto di:

const archivioStrumenti = creaArchivioStrumentiInMemoria();

Il cambio deve stare nel punto di composizione.

Passo 3: verifica il comportamento

Verifica almeno:

• registrazione strumento;
• refresh pagina;
• ricerca strumento;
• registrazione prestito, se coinvolta;
• assenza di errori tecnici visibili.

Scheda risultato

Compila:

# Micro-sfida: cambio archivio

Caso d'uso scelto:

Archivio iniziale:

Archivio finale:

File modificati:
- ...

File del caso d'uso modificato?
- [ ] no
- [ ] si

Se si, perche?

Comportamenti verificati:
- ...

Problemi trovati:
- ...

Spiegazione guidata per studiare

Questa lezione va studiata su due piani. Il primo è il comportamento visibile del Registro del laboratorio: che cosa vede o fa l’utente quando registra uno strumento, cerca un dispositivo, apre un prestito o segnala un guasto. Il secondo è il confine architetturale: dove deve stare il codice che rende possibile quel comportamento.

Per micro-sfida: cambia archivio senza modificare il caso d’uso, il punto centrale è questo: L’infrastruttura è il bordo tecnico: salva, legge, chiama API, usa localStorage o file JSON. È importante, ma deve restare sostituibile.

Il rischio tipico è far entrare il formato salvato dentro il dominio. Un oggetto comodo per localStorage non è automaticamente il modello con cui ragiona il progetto. Per evitarlo, non partire dal file che hai già aperto nell’editor. Parti dalla domanda: “quale responsabilità sto modificando?”. Se la risposta riguarda una regola del laboratorio, guarda il dominio. Se riguarda una sequenza di operazioni, guarda i casi d’uso. Se riguarda salvataggio, file, localStorage, API o database, guarda l’infrastruttura. Se riguarda input, pulsanti, form e messaggi, guarda la Presentation.

Il tempo è breve: non provare a fare tutto, punta a capire il concetto e produrre un risultato piccolo. Alla fine della lezione lo studente non deve ricordare una definizione a memoria: deve saper indicare un punto del progetto, spiegare perché quel codice sta lì e mostrare una verifica del comportamento.

Passo per passo nel progetto

1. Rileggi il titolo della lezione e riscrivilo come domanda pratica. Per esempio: “dove deve stare questa regola?”, “chi deve salvare questo dato?”, “come verifico questo errore?”.
2. Apri solo i file necessari. Se devi toccare più di tre file, fermati e scrivi prima una mini-mappa.
3. Distingui modello di dominio e formato salvato.
4. Crea una funzione di mapping leggibile.
5. Gestisci dati mancanti o non validi.
6. Verifica che i casi d’uso non cambino quando cambi archivio.
7. Aggiorna una nota breve nel README o negli appunti se hai cambiato un confine del progetto.

Esempio da leggere lentamente

Questo esempio serve a ragionare, non a incollare codice senza capire:

function strumentoToDTO(strumento) {
  return {
    id: strumento.id,
    name: strumento.nome,
    category: strumento.categoria,
    status: strumento.stato
  };
}

Leggilo chiedendoti che cosa cambierebbe se domani sostituissimo la pagina web con una CLI, oppure localStorage con un’API. Se l’esempio continua ad avere senso senza riscrivere tutto, il confine è probabilmente buono. Se invece un dettaglio tecnico si propaga in molti file, il progetto sta tornando fragile.

Prova di comprensione

Prima di chiudere la lezione, rispondi per iscritto a queste domande:

• Qual è la responsabilità principale trattata in questa lezione?
• In quale livello del progetto dovrebbe stare?
• Quale errore faresti se cercassi la soluzione più veloce?
• Quale piccolo test, controllo manuale o esempio dimostra che hai capito?
• Che cosa deve restare facile da cambiare dopo questa lezione?

Una risposta accettabile non deve essere lunga. Deve però usare parole concrete del Registro: strumento, prestito, stato, archivio, caso d’uso, messaggio, test.

Risultato atteso

La sfida e riuscita se:

Il caso d'uso non cambia.
Il nuovo archivio rispetta il contratto.
La composizione sceglie l'implementazione.
Il comportamento resta uguale per l'utente.

Controllo finale del modulo

Il Modulo 10 e completato quando puoi rispondere si:

• so cosa appartiene a Infrastructure;
• so salvare e leggere da localStorage;
• so distinguere dominio e DTO;
• so scrivere mapping tra DTO e dominio;
• so gestire almeno dati mancanti o corrotti in modo minimo;
• so spiegare cosa fa un adapter;
• posso cambiare archivio senza modificare il caso d’uso.

Nel prossimo modulo torniamo sulla Presentation: la UI come bordo del sistema, senza regole di dominio nascoste dentro form, bottoni e rendering.