Idea principale

Un'eccezione chiamata ElementAnnuléNonModifiable non è un messaggio di errore: è una regola del business scritta in codice, leggibile da un operatore del supporto che non programma. Un'eccezione chiamata InvalidStateException dice la stessa cosa al processore e niente a nessun altro. È questo scarto, e non la qualità tecnica del repository, a decidere se una domanda di prodotto può trovarvi la sua risposta.

La condizione vale per tutto il materiale: entità che portano i nomi usati dagli utenti, azioni il cui nome si capisce, eventi che raccontano ciò che è successo, policy che rendono visibili le reazioni a catena, moduli dalla struttura prevedibile. Un repository in cui i concetti del dominio sono nascosti dietro nomi tecnici e le regole sono sparpagliate resta opaco, qualunque sia la cura messa nella sua suddivisione o nella sua copertura di test.

L'esigenza è antica — gli approcci di progettazione guidata dal dominio la sostengono da tempo — e non l'ha creata l'arrivo degli assistenti. Uno sviluppatore che riprende un repository del genere paga la stessa traduzione continua tra il bisogno del business e la meccanica del software; ogni evoluzione richiede di ricostruire quel legame, ogni ricerca di una regola costa di più. Ciò che cambia con la possibilità di interrogare il codice è che questo difetto diventa misurabile dall'esterno del team tecnico: non si traduce più in una lentezza diffusa, ma in risposte che nessuno riesce a ottenere.

Perché è importante

Sposta il criterio da applicare prima di installare un sistema di interrogazione. La domanda da porre a un repository non è «è ben tenuto?» ma «c'è scritto il vocabolario del dominio?» — due proprietà che si incontrano spesso insieme ma non hanno un legame necessario.

Dà anche un argomento non tecnico a un investimento che ne aveva solo uno tecnico. Rinominare i concetti nella lingua del business smette di essere una preferenza da artigiano nel momento in cui il supporto, la prevendita e il product management ne dipendono per ottenere risposte.

Sfumature e limiti

L'uniformità non esiste: uno stesso repository parla la lingua del business nel modulo di fatturazione, scritto vent'anni prima da persone che conoscevano il dominio, e resta muto nello strato di integrazione. La condizione si verifica zona per zona, non sull'intero repository.

Il vocabolario fissato nel codice ha inoltre una data. Il nome di un'entità sopravvissuto a tre riposizionamenti racconta un business che non si pratica più, e proprio la sua leggibilità lo rende ingannevole.

Infine, un nome di dominio corretto può nascondere una regola sbagliata. Che un'eccezione esprima una regola la rende leggibile, non esatta: ciò che diventa interrogabile è il codice, non il prodotto voluto.

Domande aperte

• Chi decide sul vocabolario quando gli utenti chiamano un oggetto in modo diverso dal codice, e i due usi hanno i loro sostenitori in azienda?
• Come si misura, prima di avviare il lavoro, lo scarto tra il vocabolario di un repository e quello del dominio?