Linguaggio Ubiquo - conflitto tra correttezza e usabilità

Una parte fondamentale di Domain Driven Design è l'uso coerente di un linguaggio onnipresente nel sistema: conversazioni, codice, schema del database, interfaccia utente, test, ecc.

Sono coinvolto in un progetto in cui esiste già un linguaggio di dominio ben definito, definito da un'organizzazione di standard internazionali.

Tuttavia, il lavoro che stiamo svolgendo è per un sito Web pubblico e i termini "corretti" per il dominio non sono necessariamente il modo in cui il pubblico li utilizza e li comprende.

Il compromesso che stiamo utilizzando al momento è quello di utilizzare i termini "ufficiali" ovunque, ad eccezione dei nostri criteri di accettazione che si riferiscono ai componenti dell'interfaccia utente, dove utilizziamo i nomi informali.

Sembra un approccio ragionevole?

Sì, sembra ragionevole. Se il pubblico previsto non comprende i termini della tua lingua o li interpreta in modo errato, l'usabilità per l'utente finale ha la precedenza.

Un programma o contenuto che un utente tipico non comprende ha poco valore. Inoltre, se si desidera presentare loro solo una punta semplificata di un iceberg perché non sono e non saranno mai esperti di dominio.

Normalmente, quando parli del dominio durante lo sviluppo, allora tutti comprendono la lingua perché è accurata e tutte le persone sono all'interno del dominio. Ma se il valore aziendale viene creato dalla comunicazione dei contenuti agli estranei al dominio, farlo nel modo più semplice possibile. Usa parole e lingue che hanno meno probabilità di essere fraintese e usale nell'interfaccia utente.

Mantieni la lingua accurata nel tuo codice e per comunicare con le persone interessate al dominio. Queste sono le persone che hanno le specifiche e che sono gli utenti chiave delle applicazioni, quelle con cui discutete i dettagli logici aziendali. Nel raro caso in cui si discute davvero della maggior parte dei dettagli logici aziendali con utenti che non hanno molta idea del dominio e non è necessario immergersi in profondità in esso, quindi incorporare la loro lingua nella lingua del dominio, dato che hanno un linguaggio comune e inequivocabile (che probabilmente non è il caso).

Ma assicurati che gli sviluppatori frontend siano a conoscenza dei tuoi termini informali e dei loro corrispondenti termini di dominio.

Penso che il modo più semplice per rispondere a questo sarebbe tracciare la linea esattamente dove lo disegneresti se presentassi l'interfaccia utente in una lingua completamente diversa.

Se i tuoi utenti finali avessero bisogno di vedere cose in sanscrito, come potresti colmare la differenza tra l'interfaccia utente e il codice (e altre comunicazioni interne).