La mia lettura, continua ed ho una curiosità da sciogliere con voi
del gruppo.
Per la formazione di un "Ubiquitous language" coinciso ed efficace
c'è sempre l'eterno dilemma su quale
linguaggio naturale adottare per il proprio "domain model".
Noi qui in Softcare dopo diversi anni siamo arrivati a scegliere
l'inglese come linguaggio naturale e quindi tutti gli oggetti, i
metodi, le tabelle, ecc. vengono chiamati con nomi in inglese. Il
vantaggio credo sia per tutti ovvio nel momento in cui abbiamo una
sintassi del linguaggio di sviluppo che utilizza parole in inglese
(foreach, if, equals,...)
Questo però porta a dei problemi di continua traduzione quando ci
troviamo a lavorare su progetti che sono esclusivamente in
lingua "italiana". In questi casi gli utenti parlano sempre in
italiano e noi facciamo un grande sforzo per tradurre tutto in
inglese introducendo un elemento (la traduzione) che ostacola non
poco la costruzione di un buon "Ubiquitous language".
In realtà una soluzione a questo dilemma non esiste: abbiamo 2
vincoli (linguaggio di sviluppo in inglese e dominio del problema in
italiano) e quindi ci rimangono 2 soluzioni:

a) Inglese/Inglese (con traduzione)
b) Inglese/Italiano (senza traduzione)

Voi quale preferite?
Secondo voi qual'è la soluzione che permette la costruzione di un
vero "Ubiquitous language"?


Sono proprio curioso. Resto in ascolto...

Grazie,
Ciao Alex

Penso che sia un problema non solo legato al DDD, in generale credo sia
comunque bene utilizzare il linguaggio naturale che parlano i clienti,
quindi in Italia tipicamente l'italiano. Il più delle volte chi sviluppa già
ha un lessico totalmente diverso da quello del business, che è il problema
per cui si vuole un ubiquitous language, se poi ci metti in mezzo anche la
traduzione (e tipicamente non è che tutti sono bilingui di natura) si
aggiunge un ulteriore impedimento. Noi rimaniamo sul semplice e usiamo
l'italiano.

Purtroppo questo rovina l'eleganza del codice, perché mescola, come dicevi,
italiano e inglese, ma tutto sommato credo che sia il male minore.

Andrea
http://andreamoz.blogspot.com

> -----Original Message-----
> From: DDD-IT@yahoogroups.com [mailto:DDD-IT@yahoogroups.com]
> On Behalf Of ruggeri.alex
> Sent: Monday, February 09, 2009 5:03 PM
> To: DDD-IT@yahoogroups.com
> Subject: [DDD-IT] Ubiquitous language: italiano vs inglese
>
>
> La mia lettura, continua ed ho una curiosità da sciogliere con voi
> del gruppo.
> Per la formazione di un "Ubiquitous language" coinciso ed efficace
> c'è sempre l'eterno dilemma su quale
> linguaggio naturale adottare per il proprio "domain model".
> Noi qui in Softcare dopo diversi anni siamo arrivati a scegliere
> l'inglese come linguaggio naturale e quindi tutti gli oggetti, i
> metodi, le tabelle, ecc. vengono chiamati con nomi in inglese. Il
> vantaggio credo sia per tutti ovvio nel momento in cui abbiamo una
> sintassi del linguaggio di sviluppo che utilizza parole in inglese
> (foreach, if, equals,...)
> Questo però porta a dei problemi di continua traduzione quando ci
> troviamo a lavorare su progetti che sono esclusivamente in
> lingua "italiana". In questi casi gli utenti parlano sempre in
> italiano e noi facciamo un grande sforzo per tradurre tutto in
> inglese introducendo un elemento (la traduzione) che ostacola non
> poco la costruzione di un buon "Ubiquitous language".
> In realtà una soluzione a questo dilemma non esiste: abbiamo 2
> vincoli (linguaggio di sviluppo in inglese e dominio del problema in
> italiano) e quindi ci rimangono 2 soluzioni:
>
> a) Inglese/Inglese (con traduzione)
> b) Inglese/Italiano (senza traduzione)
>
> Voi quale preferite?
> Secondo voi qual'è la soluzione che permette la costruzione di un
> vero "Ubiquitous language"?
>
>
> Sono proprio curioso. Resto in ascolto...
>
> Grazie,
> Ciao Alex
>
>
>
> ------------------------------------
>
> Link utili di Yahoo! Gruppi
>
>
>

Io ho sempre fatto delle scelte molto drastiche in questo contesto,
avendo a che fare spesso con ORM che generano metodi con tanto di forme
plurali (inglesi, con la 's').

Scelgo sempre la via esterofila.

Se gli esperti di dominio parlano solo italiano io e il team ci
assumiamo l'intero onere della traduzione sul fronte 'interno',
mostrando all'"esterno" un linguaggio condivisibile interamente in
italiano.

Se gli sviluppatori hanno problemi con l'inglese... uhm... ci deve
essere stata qualche deviazione in fase di recruitment...
A mio avviso il team DEVE essere (quasi?) perfettamente anglofono, a
priori.

Ciau!

--
Jacopo Romei <jakuza@...>

Grazie ad Andrea e Jacopo per le vostre risposte.
Qualcun'altro?
Coraggio! Non c'è una risposta giusta ed una sbagliata, è solo un
sondaggio per vedere quale scelta (in ogni caso forzata visto che non
c'è una soluzione ottimale) abbiamo fatto e perchè.

Alex

> Se gli sviluppatori hanno problemi con l'inglese... uhm... ci
> deve essere stata qualche deviazione in fase di
> recruitment... A mio avviso il team DEVE essere (quasi?)
> perfettamente anglofono, a priori.

A livello concettuale sono perfettamente d'accordo con te, però anche io
volevo fare il figlio di un miliardario texano... A volte ci si deve
accontentare e lavorare con quello che si ha (ci sarà un motivo se si parla
di Scrum come "the art of possible"), il che include - per quanto possa
sembrare assurdo - sviluppatori che hanno problemi, anche seri, con
l'inglese.

Ne approfitto per confessare che nel mio post precedente non avevo
considerato le implicazioni indicate dallo zio Brando nel suo blog... c'è
veramente sempre da imparare!

Andrea
http://andreamoz.blogspot.com

Al mio post avevo aggiunto tutti i 'disclaimer' che sapevo (ma speravo
non) necessari alla perentorietà della mia dichiarazione, che voleva
essere più sintetica che perentoria. Chiedo venia.

> A livello concettuale sono perfettamente d'accordo con te

E allora siamo d'accordo al 100%.
Il... 'diff' :) tra teoria e prassi è una tara che nei nostri discorsi
possiamo accordarci di considerare sempre a priori.

Nella prassi ogni situazione richiederà una soluzione ad hoc, poco ma
sicuro. Però forse l'unico elemento di perentorietà che mi sentirei di
conservare della mia precedente dichiarazione è questo: i membri del
team si possono anche cambiare e sul mercato degli sviluppatori c'è
abbastanza offerta per trovarne uno che parli mezza parola di inglese...

Anche perché chi fra noi non parla inglese al livello minimo richiesto
per condividere un vocabolario di dominio non ha nemmeno letto mezzo
libro di quelli che ogni iscritto a questa ml (o affini) ama tanto.

No?
>
--
Jacopo Romei <jakuza@...>

> Nella prassi ogni situazione richiederà una soluzione ad hoc,
> poco ma sicuro. Però forse l'unico elemento di perentorietà
> che mi sentirei di conservare della mia precedente
> dichiarazione è questo: i membri del team si possono anche
> cambiare e sul mercato degli sviluppatori c'è abbastanza
> offerta per trovarne uno che parli mezza parola di inglese...

Questo è vero... Anche se non sempre è semplice cambiare, a suo tempo avevo
scritto qualcosa qui
http://andreamoz.blogspot.com/2008/10/putting-people-first.html e qui
http://andreamoz.blogspot.com/2008/07/voting-someone-off-island-on-agile-tea
m.html

> Anche perché chi fra noi non parla inglese al livello minimo
> richiesto per condividere un vocabolario di dominio non ha
> nemmeno letto mezzo libro di quelli che ogni iscritto a
> questa ml (o affini) ama tanto.

Triste ma vero... Molto triste e molto vero. Purtroppo, se posso aggiungere,
conoscere l'inglese non è condizione sufficiente per avere letto almeno
mezzo libro di quelli a cui ti riferisci.

Ne approfitto per segnalare la lista dei 100 migliori libri di ingegneria
del software: la trovate qua
http://knol.google.com/k/jurgen-appelo/top-100-best-software-engineering-boo
ks/z7e4mx2g6lir/3#The_Top_100_List anche se io ci sono arrivato passando dal
blog di Gabriele http://www.gabrielelana.it/archives/90

> - la traduzione a beneficio degli esperti di dominio è una sorta di
> "negazione" dello Ubiquitous language. Di fatto stiamo
ufficializzando il
> fatto che ne abbiamo due.

Leggendo il libro di Evans è la sensazione che ho avuto anche io.

Alex

In effetti non so cominciare questo post.

Da un lato sono ancora frastornato dalla partecipazione al DDD Exchange di
Londra, dall'altro ho una vocina che mi dice: "Brando, sei un patacca! Non puoi
non parlare del DDD Exchange sulla mailing list di Domain Driven Design!", per
cui comincio facendo ammenda: tra le mille cose da fare e le notti insonni non
sono riuscito a trovare il tempo per un post che anticipasse l'evento.

Mi cospargo il capo di cenere.

Ma credo che a questa mailing list interessino più i fatti che i problemi di
coscienza del moderatore. Oggi finalmente ho tempo e provo a recuperare.

L'evento cui faccio riferimento è:
http://skillsmatter.com/event/design-architecture/ddd-exchange

organizzato da Skills Matter (l'azienda per la quale tengo corsi di tanto in
tanto, in giro per l'Europa). Tra gli speaker Eric Evans, Gojko Adzic (autore di
"Bridging the Communication Gap"), Dan Haywood (Naked Objects), Phil Wills
(responsabile di un reference project in DDD per The Guardian), Hans Dockter
(autore di Gradle) ed il sottoscritto (fondamentalmente nel ruolo di "uno che ha
visto un bel po' di casini").

L'organizzazione è stata notevole. Potete già trovare online sul sito
dell'evento i link ai video di tutti gli interventi.

Eric Evans ha affrontato il problema della gestione del codice legacy, mostrando
come sia in generale una pessima idea quella di riscrivere una legacy code base,
e come sia meglio cercare apoggi più pragmatici che permettano la scrittura di
buon codice in un oasi protetta "dove serve".
Qui trovate il video del suo intervento:
http://skillsmatter.com/podcast/design-architecture/keynote-domain-drive-design
E qui un ottimo riassunto scritto da Gojko nel frattempo:
http://gojko.net/2009/06/19/eric-evans-why-do-efforts-to-replace-legacy-systems-\
fail/

Nel mio intervento ho parlato di una tecnica nota come Context mapping e di come
possa essere utilizzata con successo come tool di supporto decisionale anche in
contesti in cui DDD non è praticabile. Uno dei punti chiave è che le
organizzazioni si riflettono nel modo in cui producono software: il processo di
realizzazione di una Context Map ha come obiettivo l'individuazione dei
differenti modelli presenti in un'applicazione, ma in genere porta ad esporre le
disfunzioni dell'organizzazione in cui questa viene sviluppata.
Qui trovate il video:
http://skillsmatter.com/podcast/design-architecture/context-mapping-in-action
e qui i lucidi:
http://www.slideshare.net/ziobrando/context-mapping-in-action

nei prossimi giorni conto di approfondire sul blog un po' dei punti che ho
toccato.

Phil Wills ha presentato la success story del rifacimento del sito del Guardian,
secondo i principi di Domain Driven Design: per me è stato interessante notare
come il "breakthrough" sia scattato quando hanno smesso di "pensare legacy".

Gojko Adzic ha affrontato il problema della sviluppo software distribuito (anche
"largamente distribuito") mostrando come gli aggregati possono esere utilizzati
in vari contesti aumentando la scalabilità di applicazioni anche estremamente
complesse.
Video:
http://skillsmatter.com/podcast/design-architecture/gojko-adzic-on-domain-driven\
-design
Blog Post:
http://gojko.net/2009/06/23/improving-performance-and-scalability-with-ddd/

Dan Haywood ha mostrato come sia stato possibile combinare DDD e la potenza di
Naked Object per lo sviluppo di un software per le gestione del sistema
pensionistico irlandese. E come questo abbia instaurato un circolo virtuoso di
collaborazione con i Domain Expert, come effetto combinato di Ubiquitous
Language, processo di sviluppo e nuovi metodi di collaborazione.
Video:
http://skillsmatter.com/podcast/design-architecture/exploring-domains-and-collab\
orating-with-domain-experts

Infine Hans Dockter ha mostrato come i principi di Domain Driven Design siano
alla base della progettazione del build system Gradle, che s sta imponendo come
alternativa interessante al duopolio Ant - Maven.
Video:
http://skillsmatter.com/podcast/design-architecture/ddd-and-the-gradle-build-sys\
tem

Ma la parte più interessante è stata forse il panel finale, strutturata secondo
il meccanismo della "panchina del parco" in cui a turno ci si alternava
proseguendo nel flusso della discussione.
Anche di questa è disponibile il video.
http://skillsmatter.com/podcast/design-architecture/panel-discussion-832
(a onor del vero tra l'ultimo talk ed il panel è girata un po' di birra...).

Per ora è tutto, ho un po' di cose che mi frullano in testa, ma ... per il
prossimo post.

Alla prossima!

Brando

Ciao a tutti,

Fresco fresco su QCon è stato pubblicato il video sulla presentazione di Greg
Young sulla Command Query Separation in Distributed DDD.

E' decisamente interessante:

http://www.infoq.com/presentations/greg-young-unshackle-qcon08

Brando

2009/8/25 Alberto Brandolini <alberto.brandolini@...>:
>
>
> Buongiorno a tutti.
>
> Una piccola war-story sull'interazione con il Domain Expert e la gestione
> del Breakthrough.
>
[cut]
> Soprattutto: oltre ad essere risorse preziose per il progetto (e fra quelle
> non sostituibili) i DE sono persone, ognuna fa storia a se, per cui non
> abbiamo "regole sicure" da seguire, quello che ha funzionato in un contesto
> può essere un problema in altri. Il nostro obiettivo è la "creative
> collaboration" ma non è detto che sia necessariamente anche il loro: a
> volte, stabilire una modalità di comunicazione efficace è semplice e quasi
> naturale. Altre volte richiede notevoli accomodamenti e molta (ma
> ...veramente tanta) capacità di adattamento.
>
> ... qualcuno si è trovato in situazioni simili?
>

Qualche anno addietro. Mi sono trovato a lavorare con persone
"complesse dentro". Io maneggio le cose complicate con difficoltà, se
trovo il modo di semplificare mi ci butto a pesce.
Invece lì godevano della complessità.  E' stata dura, ma
fortunatamente il rapporto umano era molto buono e siamo riusciti
piano piano a fare le cose come andavano fatte.

Oggi come oggi, dove mangio il mio stesso codice e sono anche esperto
di una parte consistente del dominio, spesso mi trovo a ridiscutere il
me-stesso di mesi addietro :)
Non discuto da solo, non più :)

FRANK

--
Roberto Franchini
http://www.celi.it
http://www.blogmeter.it
http://www.memesphere.it
Tel +39-011-6600814
jabber:ro.franchini@... skype:ro.franchini

> La lezioncina che mi sono dato è qualcosa del genere: "Brando, prima di
> credere di essere in territorio amico, perlustra il territorio"

Probabilmente vale la pena non ritenere alcun territorio come
sufficientemente amico, mai. La pratica del 'judo dialettico' - come
la definisce Kundera - richiede una guardia sempre alta, purtroppo.

p.s. vi piace la ventata di ottimismo che ho portato??? :)

--
Jacopo Romei
http://www.sviluppoagile.it/

2009/8/28 Jacopo Romei <jakuza@...>:
>
>
>> La lezioncina che mi sono dato è qualcosa del genere: "Brando, prima di
>> credere di essere in territorio amico, perlustra il territorio"
>
> Probabilmente vale la pena non ritenere alcun territorio come
> sufficientemente amico, mai. La pratica del 'judo dialettico' - come
> la definisce Kundera - richiede una guardia sempre alta, purtroppo.
>
> p.s. vi piace la ventata di ottimismo che ho portato??? :)

Quindi piove tutto il weekend?
FRANK

--
Roberto Franchini
http://www.celi.it
http://www.blogmeter.it
http://www.memesphere.it
Tel +39-011-6600814
jabber:ro.franchini@... skype:ro.franchini

Mi sono spiegato male - strano in una riga sola! :)

Brando: Con 'guardia alta' intendevo proprio la necessità di essere
vigile *mentre* manteniamo anche le condizioni per lasciare che il
fallimento emerga. Non intendevo un atteggiamento preventivo.

Frank: Il mio approccio è sistematico e non ansioso. Pioverà tutto il
weekend? Intanto portiamoci la cerata e l'ombrello e preoccupiamoci di
non occupare tutto il bagaglio con questi due accessori. Poi 'postpone
decision as much as you can'. E soprattutto senza fasciarsi la testa.

No, davvero: trovo che disaccoppiare l'aspettativa dal rischio sia
fondamentale nel gestire le "cose" umane. Rischio di pioggia
sempiterno, certezza di corruzione della serenità mai. Credo dovrebbe
essere così. Occhio al condizionale però. ;)

--
Jacopo Romei
http://www.sviluppoagile.it/

> La prossima volta porto la mamma a coprirmi le spalle. :-)

Basta un buon collega romano ;)

--
Jacopo Romei
http://www.sviluppoagile.it/

2009/8/28 Alberto Brandolini <alberto.brandolini@...>:
>
>
> Il giorno 28 agosto 2009 15.26, Jacopo Romei <jakuza@...> ha scritto:
>>
>>
>> Mi sono spiegato male - strano in una riga sola! :)
[cut]
>
> La prossima volta porto la mamma a coprirmi le spalle. :-)
>

Ma, se vuoi vengo io :) occhiale nero, maglietta nera, giacca di pelle
nera e fucile a pompa di ordinanza, vado bene?
  FRANK

--
Roberto Franchini
http://www.celi.it
http://www.blogmeter.it
http://www.memesphere.it
Tel +39-011-6600814
jabber:ro.franchini@... skype:ro.franchini

2009/8/28 Alberto Brandolini <alberto.brandolini@...>:
>
>
> ... bella Frank.
[cut]
> La lezioncina che mi sono dato è qualcosa del genere: "Brando, prima di
> credere di essere in territorio amico, perlustra il territorio", chiarire
> cos'è il brainstorming potrebbe non essere sufficiente. In molti casi la
> soluzione ideale è "brainstorming con i tuoi, poi discuti con l'esperto".
>

Soprattuto all'nizio della mia carriera, inconsciamente pensavo che
TUTTI fossero propensi come me al cambiamento, alla scoperta, finanche
alla rivoluzione.
E' un po' la questione che tirai fuori tempo addietro su xp-it
riguardo alla volontà di imparare cose nuove.
Dopo un po' di batoste caominci a capire che NON TUTTI sono come te,
che chi ha il suo orticello spesso non è propenso a farti entrare e
rivoluzionare tutto.
Poi torvi quelli come te, e allora è una pacchia. In poco tempo puoi
creare delle cose fantastiche, buttarle via rifarle da 0 perchè
insieme avete capito che è il momento del breakthrough.
Ci sono vari livelli di niterazione, e quello tecnico viene molto dopo
quello umano.
FRANK
--
Roberto Franchini
http://www.celi.it
http://www.blogmeter.it
http://www.memesphere.it
Tel +39-011-6600814
jabber:ro.franchini@... skype:ro.franchini

Volevo segnalarvi questo interessante post di Gojko Adzic:
http://gojko.net/2009/09/30/ddd-and-relational-databases-the-value-object-dilemm\
a/

Dopo averlo letto, il dilemma rimane intatto...
Se ho bisogno di fare ricerche (query) sui singoli attributi di un value object
(95% dei casi) quale dei 3 metodi scegliereste?

Alex Ruggeri

Ciao a tutti,

il mese di novembre si annuncia piuttosto "caldo" per quanto mi riguarda (un
sacco di roba che bolle in pentola...) ma in particolare per quanto riguarda DDD
avrò modo di affrontare l'argomento in 2 giornate alla JAX conference di Milano.

In particolare venerdì 13 novembre farò un intervento dal titolo "Gestire la
complessità con Domain Driven Design" di livello entry-intermediate (ma su
argomenti che partono dagli articoli già pubblicati su Mokabyte per "andare
oltre"), mentre il sabato sono a disposizione per l'intera giornata (ok, sono 6
ore... ma è sabato) per un power workshop su DDD, in cui cercherò di condensare
un po' degli argomenti che affrontiamo normalmente nei corsi DDD che normalmente
faccio in Inghilterra.

Ovviamente negli altri giorni della conferenza "ronzerò" attorno...

La settimana successiva sarò all'Agile Day a Bologna con un intervento non
strettamente correlato a DDD (ma la forma mentis ...è quella), e con la
possibilità di fare un mini-workshop (di 2 ore massimo però) su Strategic DDD
(ancora in "ballottaggio" però).

Ovviamente siete tutti i benvenuti.

Brando