Al meccanico non interessa di che colore è l'auto

«Cosa intendi per dominio?» Me l’ha chiesto un collega mentre decidevamo se il nome del fornitore dovesse entrare nel dominio. Era la domanda giusta: finché non è chiaro cos’è il dominio, non si può decidere cosa ci entra.

Gli ho risposto prima con la teoria: il dominio è l’ambito di conoscenza e di attività che il software deve servire. È una definizione corretta, ma resta astratta. Non aiuta a capire se il fornitore sta dentro o fuori.

Per spiegarmi meglio gli ho fatto una similitudine con un’officina.

La stessa auto, tre schede diverse

Porta l’auto in officina. Il meccanico ti chiede quanti chilometri ha, quando hai fatto l’ultimo tagliando, che rumore senti e quando. Poi la collega alla diagnosi e legge i codici errore. Di che colore sia non te lo chiede: non cambia niente di quello che deve fare.

Il carrozziere parte proprio da lì. Gli servono il codice della vernice e le ammaccature, mentre dei chilometri non gli importa nulla. In ufficio l’auto non la guardano nemmeno: vogliono il nome del proprietario, l’indirizzo e la partita IVA per la fattura.

Stessa auto, tre schede diverse. Nessuna è sbagliata e nessuna è completa. Ognuna contiene quello che serve a chi la usa per fare il suo lavoro e niente di più.

Il dominio è questo: l’attività che il programma deve servire, con le regole e le parole di chi ci lavora da anni. Se il programma è quello del meccanico, il dominio è il suo lavoro: tagliandi, guasti, riparazioni. Il modello è la parte del dominio che scegliamo di rappresentare nel codice. Per essere precisi, meccanico, carrozziere e ufficio lavorano in reparti diversi della stessa officina (chi scrive software li chiama sottodomini). Ma la sostanza non cambia: ognuno ha le sue regole, le sue parole e la sua scheda.

Il modello è una scelta

Non è un’idea mia. Eric Evans, nel libro del 2003 che ha dato il nome al domain-driven design, descrive il modello come una semplificazione: un’interpretazione della realtà che tiene gli aspetti utili a risolvere il problema che si ha davanti e ignora il resto. Il modello non è una fotografia del dominio. È una scelta. E scegliere vuol dire anche decidere cosa resta fuori.

Evans insiste anche su un’altra cosa: quella scelta non la fa da solo chi scrive il codice. Si fa parlando con chi quel lavoro lo fa ogni giorno, finché chi programma e chi lavora in officina usano le stesse parole.

Il test della decisione

Il test che uso è una domanda: questa informazione è rilevante per il lavoro che l’applicazione deve fare? Il modo più semplice per rispondere è chiedersi se c’è una decisione che cambia in base a lei.

Il colore non entra nel dominio: il meccanico non fa niente di diverso su un’auto rossa o su una blu. I chilometri sì, perché decidono se è ora del tagliando e cosa va sostituito. Nemmeno l’indirizzo del proprietario entra: serve all’ufficio, non al meccanico.

La risposta però non la dà chi scrive il codice. In officina la chiedi al meccanico. Le domande che aiutano sono poche. Questa informazione cambia una regola o una decisione? La nomina da solo quando racconta come lavora? Sta lì solo perché la vuole una schermata, un report o un altro sistema? Se la togliamo, il suo lavoro diventa impossibile o solo un po’ meno comodo?

La rilevanza non è fissa: la crea una regola. L’indirizzo resta fuori dal lavoro del meccanico finché l’officina non comincia a offrire il ritiro dell’auto a domicilio e a decidere se accettarlo in base alla distanza. Da quel giorno entra, perché c’è una decisione che dipende da quel dato. Tenerlo dentro prima “perché potrebbe servire” è come scrivere il colore sulla scheda del meccanico: nessuno sa perché c’è.

Il fornitore, da cui era partita la discussione, si decide allo stesso modo. Al meccanico interessa sapere che pezzo sta montando, cioè le pastiglie giuste per quell’auto, non da chi arrivano. Che le abbia vendute il fornitore 1 o il fornitore 2 non cambia niente di quello che fa. Per questo il fornitore resta fuori dalla sua scheda.

Fuori dalla scheda del meccanico, però, non vuol dire fuori dall’officina. Per chi fa gli acquisti il fornitore è centrale: con lui tratta i prezzi, a lui telefona quando un pezzo non arriva. Le due cose sono vere insieme. Si decide reparto per reparto, non una volta per tutta l’officina.

Anche il fornitore potrebbe entrare, il giorno in cui una regola lo chiede. Se l’officina decidesse di dare una garanzia diversa ai ricambi originali e a quelli compatibili, al meccanico servirebbe sapere di che tipo è il pezzo che monta. Ma entrerebbe con il nome della regola, originale o compatibile, non con il nome del fornitore.

Rilevante non vuol dire disponibile

Un’informazione non entra nel dominio solo perché ce l’abbiamo. Il colore dell’auto è scritto sul libretto, copiarlo non costa niente. Non per questo serve al meccanico.

Vale anche al contrario: lasciare fuori non vuol dire buttare. Il fornitore resta a chi fa gli acquisti, l’indirizzo all’ufficio. Il test decide dove sta un’informazione, non se merita di esistere. Quello che resta fuori, però, può cambiare quando vuole: come tenerlo al confine l’ho raccontato in un altro pezzo.

Il meccanico poi è un’immagine comoda proprio perché è uno. In un’officina vera da sentire ce ne sono di più: il meccanico, il capofficina che organizza il lavoro, chi accoglie i clienti al banco. In un progetto software si chiamano stakeholder, cioè tutte le persone che hanno qualcosa in gioco in quello che il programma fa. Raramente raccontano le stesse regole allo stesso modo e a volte non sono d’accordo tra loro. Il test resta lo stesso, ma la risposta va cercata parlando con tutti, non con uno solo.

Se hai una tua domanda per decidere cosa entra nel modello, o un caso in cui questo test non funziona, scrivimi.

Riferimenti

• Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley Professional, 2003 (scheda dell’editore): il modello come semplificazione che tiene solo gli aspetti utili al problema.