Programming and Ubiquitous Language (DDD) in un dominio non inglese

Question

Programming and Ubiquitous Language (DDD) in un dominio non inglese

#1 da (10 voti)
#2 da (4 voti)
#3 da (3 voti)
#4 da (2 voti)

59

So che ci sono già alcune domande che sono strettamente correlate a questo argomento ma nessuno di loro prende Lingua Ubiquitous come Punto quindi penso che giustifichi questa domanda.

Per chi non lo sapesse: Ubiquitous Language è il concetto di definizione di un linguaggio (sia parlato che scritto) che viene utilizzato ugualmente tra sviluppatori e esperti di dominio per evitare incoerenze e problemi di comunicazione dovuti a problemi di traduzione e incomprensioni. Vedrai la stessa terminologia apparire nel codice, conversazioni tra qualsiasi membro del team, specifiche funzionali e quant'altro.

Quindi, quello che mi stavo chiedendo è come trattare con Ubiquitous Language in domini non inglesi.

Personalmente, sono strongmente favorevole alla scrittura del codice di programmazione in inglese completamente, compresi i commenti ma naturalmente escludendo costanti e risorse.

Tuttavia, in un dominio non inglese, sono costretto a prendere una decisione a:

Scrivi un codice che rifletta l'Ubiquitous Language nella lingua naturale del dominio.
Traduci la lingua onnipresente in inglese e smetti di comunicare nel linguaggio naturale del dominio.
Definisci una tabella che definisce il modo in cui l'Ubiquitous Language si traduce in inglese.

Ecco alcuni dei miei pensieri basati su queste opzioni:

1) Ho una strong avversione nei confronti del codice a linguaggio misto, cioè la codifica usando nomi di tipo / membri / variabili ecc. che non sono inglesi. La maggior parte dei linguaggi di programmazione "respira" l'inglese in larga misura e la maggior parte della letteratura tecnica, i nomi dei modelli di progettazione ecc. Sono anche in inglese. Pertanto, nella maggior parte dei casi non c'è modo di scrivere codice interamente in una lingua non inglese, quindi si finisce comunque con lingue miste.

2) Questo costringerà gli esperti di dominio a iniziare a pensare e a parlare nell'equivalente inglese dell'UL, qualcosa che probabilmente non verrà loro naturale e quindi ostacola significativamente la comunicazione.

3) In questo caso, gli sviluppatori comunicano con gli esperti del dominio nella loro lingua nativa mentre gli sviluppatori comunicano tra loro in inglese e, soprattutto, scrivono il codice usando la traduzione inglese dell'UL.

Sono sicuro che non voglio andare per la prima opzione e penso che l'opzione 3 sia molto meglio dell'opzione 2. Cosa ne pensi? Mi mancano altre opzioni?

Aggiorna

Oggi, circa un anno dopo, avendo affrontato questo problema su base giornaliera, devo dire che l'opzione 3 ha funzionato abbastanza bene per me.

Non era così noioso come inizialmente temevo e la traduzione in tempo reale mentre parlavo con il cliente non era un problema.

Ho trovato anche i seguenti vantaggi, in base alla mia esperienza.

La traduzione dell'UL ti fa prestare maggiore attenzione alla definizione dell'UL e persino del dominio stesso, soprattutto quando non sai come tradurre un termine e devi iniziare a cercare tra i dizionari, ecc. Questo mi ha persino indotto a riconsiderare decisioni sulla modellazione del dominio alcune volte.
Ti aiuta a rendere più profonda la tua conoscenza della lingua inglese.
Ovviamente, il tuo codice è molto più piacevole da guardare invece di essere un'oscenità da capogiro.

domain-driven-design spoken-languages

posta Sandor Drieënhuizen 29.01.2011 - 11:45

fonte

4 risposte

Leggi altre domande sui tag domain-driven-design spoken-languages

"Funzionava ieri, lo giuro!" Che cosa puoi fare? [chiuso] Come gestisco la paralisi dell'analisi?

score 10 · Answer 1

Ho affrontato questo problema spesso, e secondo me la risposta è: "non esiste una singola risposta valida per tutti gli scenari".

Ma tieni presente che l'Ubiquitous Language non è un obiettivo di per sé. È uno strumento per rafforzare la comunicazione tra il team e gli esperti di dominio e rafforzare la coerenza concettuale del modello implementato in codice, test e conversazione.

Se riesci a parlare UL in modo inequivocabile, sei sulla strada giusta. Se tu e i tuoi coetanei traducete continuamente da codice a conversazione o da concetto a concetto, probabilmente siete fuori strada.

In pratica, non tutti i domini sono uguali, né esperti di dominio. Alcuni domini hanno comunque un sacco di terminologia inglese (domini basati sulla tecnologia, ad esempio) e sembra ragionevole optare per una scelta inglese completa. Tuttavia, alcune culture potrebbero influenzare questa scelta (il francese viene in mente) e la diffusione della terminologia inglese varia da paese a paese. In alcuni altri domini (legale, per nominarne uno) non è possibile tradurre alcuni termini. Oppure la traduzione renderebbe assolutamente più difficile per l'Esperto dominio seguire la conversazione.

In generale, siamo più interessati a ciò che l'esperto di domini ha da dire. Quindi vogliamo rendere le cose facili per loro. Altrimenti potevano semplicemente prendere una classe UML e leggere i nostri diagrammi (era uno scherzo). Quindi l'unica vera raccomandazione qui è: "fai attenzione al comportamento degli Esperti di Dominio", se sono impegnati nella conversazione e la conversazione procede senza intoppi, probabilmente sei sulla buona strada, mantieni la quella lingua . Potrebbe causare un piccolo lavoro in più sul team, ma va bene. Come sviluppatori siamo in qualche modo addestrati a imparare parole con significato specifico in un contesto.

Stranamente, questa domanda è sempre accompagnata dal presupposto che tutto il codice debba parlare una lingua. Anche questo potrebbe essere sfidato. Non sono un inglese nativo, e la conoscenza di una lingua straniera non è piatta: il mio cervello va veloce quando parla di nome , cognome , auto e simili, mancano alcuni dettagli quando si parla di zipcode , rallenta quando si parla di prestito e si richiede sicuramente una spiegazione rassicurante quando si parla di mutuo .

Quindi, ancora una volta, scegli la combinazione migliore che farà fluire la conversazione chiave e fornirà la massima quantità di informazioni e feedback dall'esperto del dominio.

score 4 · Answer 2

Di solito considero certe parole tecniche come linguistiche neutre anche se c'è una traduzione nell'altra lingua.

Ad esempio, quando parlo di codifica in tedesco, uso ancora il vocabolario tecnico inglese come se fossero parole tedesche anche se esiste un equivalente tedesco.

Nel tuo caso farei il contrario. Importa alcune parole tecniche dalla tua lingua madre in inglese, proprio come le parole straniere sono state importate da secoli. Rendili grammaticali come parole inglesi. All'inizio sembra strano, ma ti ci abituerai.

score 3 · Answer 3

Sono d'accordo con il commento La maggior parte dei linguaggi di programmazione 'inglese , che diventa sempre un problema con gli sforzi di sviluppo multilingue

Normalmente avrei l'UL nella lingua del tuo gruppo di programmazione

Ciò che abbiamo fatto in passato è creare nuove parole che esprimano meglio gli argomenti del dominio. Con un progetto francese / inglese le parole inventate sono per lo più di lingua inglese ma con un tocco francese (non troppo difficile come lo sono le parole inglesi in ogni caso), ma questo potrebbe applicarsi a qualsiasi mix di lingue

per es.

"quantity bois"

In inglese è "quantità di legno" o "quantità di legno", in francese è "quantité de bois", quindi è abbastanza vicino per entrambi i diffusori. Questo dovrebbe ridurre la quantità di nuove parole che ogni oratore deve imparare

Quanto è grande il tuo dominio UL? Questo diventa il problema. Se è inferiore a 100 frasi chiave, puoi usare un linguaggio di stile ibrido composto, se più grande rimarrò il linguaggio predominante degli sviluppatori come di solito hanno a che fare con esso più intensamente

Pubblica un dizionario wiki / thesaurus affinché tutti possano fare riferimento come richiesto, quindi non ci sono scuse per la comprensione

score 2 · Answer 4

Recentemente ho lavorato a un progetto DDD in Svizzera, dove il dominio era tasse (in particolare l'IVA e un altro tipo di imposta ... che non è facilmente traducibile in inglese ...).

Hanno scelto la prima opzione: UL in tedesco, utilizzata anche nel codice in tedesco.

Prima di lavorare su questo progetto, avevo esattamente la stessa avversione per il codice di una lingua mista. Mi piace (ancora) avere tutto in inglese, anche se non sono un madrelingua inglese. Non sono nemmeno un madrelingua tedesco. Così, quando ho iniziato ad esplorare il codice base, sono rimasto inorridito.

Dopo un anno di lavoro su quel progetto, devo ammettere che penso che sia stata la decisione giusta in questo caso (potremmo anche aver usato il francese o l'italiano, le altre lingue ufficiali svizzere, ma la maggior parte degli attori del progetto erano madrelingua tedeschi.

Molti termini specifici del dominio non erano realmente traducibili in inglese in modo significativo. Ho dovuto comunque imparare i termini tedeschi per comunicare con il resto della squadra. Sarebbe stato più complicato dover imparare anche le traduzioni in inglese, comunque sarebbe stato inventato dal nulla.

Quindi penso che dipenda davvero dal dominio. Alcuni domini saranno davvero difficili da tradurre in inglese e non avrà molto senso.

Probabilmente dipende anche dalla lingua madre. Il tedesco è una lingua dove puoi comporre le parole più o meno allo stesso modo e soprattutto nello stesso ordine che in inglese. Ad esempio una dichiarazione delle imposte potrebbe essere una Guida alla gestione . Non sorprendentemente diverso.

Non so come farei un nome di classe equivalente in francese, ad esempio, se il termine naturale fosse "déclaration d'impôts", con l'ordine opposto e una preposizione extra nel mezzo ... E questo è solo un semplice esempio. Sarei davvero interessato se qualcuno avesse esperienza con questo tipo di nomi nelle lingue latine (francese, spagnolo, italiano, portoghese ...)!

Un'altra sfida erano le forme plurali, che in tedesco sono a volte difficilmente distinguibili dal singolare (mentre in inglese ha quasi sempre un s alla fine).

I caratteri accentati erano OK, poiché in tedesco hanno tutti un equivalente non accentuato ( ü - > ue e così via). È un altro punto in cui i francesi sarebbero più problematici ...