> Quello che volevo capire è, quando andrebbero definiti i contesti?
> Vanno definiti tutti subito o possiamo lavorare in serie?

Decisamente la seconda, in un processo graduale di emersione della
conoscenza di dominio e della corrispondenza fra il nostro modello ed
il dominio stesso.

Se la riorganizzazione in fase avanzata risulta costosa il problema è
probabilmente legato al codice, senza cercare in livelli più alti
dello stack tecnico-politico di un progetto. In queste situazioni
quindi sono utili non tanto le tecniche di DDD, ma quelle - a mio
avviso ortogonali - del refactoring e altre tipiche dello sviluppo
agile. Queste ti permetteranno di avere codice facile da mantenere e
modificare in futuro, proprio per far fronte ad una conoscenza di
dominio che ci auguriamo in crescita costante.

Vago, lo so, ma spero almeno emerga un barlume di senso, un pensiero
sulla "big picture" metodologica. :-)
Ciao!

 

Ciao Jacopo,

2010/12/21 Jacopo Romei <jakuza@...>

 

> Quello che volevo capire è, quando andrebbero definiti i contesti?
> Vanno definiti tutti subito o possiamo lavorare in serie?

Decisamente la seconda, in un processo graduale di emersione della
conoscenza di dominio e della corrispondenza fra il nostro modello ed
il dominio stesso.

Qui concordo in pieno, ed in effetti fin'ora ho fatto cosi.

 

Se la riorganizzazione in fase avanzata risulta costosa il problema è
probabilmente legato al codice, senza cercare in livelli più alti
dello stack tecnico-politico di un progetto. In queste situazioni
quindi sono utili non tanto le tecniche di DDD, ma quelle - a mio
avviso ortogonali - del refactoring e altre tipiche dello sviluppo
agile. Queste ti permetteranno di avere codice facile da mantenere e
modificare in futuro, proprio per far fronte ad una conoscenza di
dominio che ci auguriamo in crescita costante.

Ok sul refactoring. A dire il vero non mi è mai capitato ma mi chiedevo cosa succede quando il cliente "nasconde" inconsapevolmente qualcosa.

Se è un nuovo contesto in linea di massima non dovrebbe creare problemi, basta aggiungere il nuovo contesto e identificare le eventuali connessioni con quelli esistenti.

Vago, lo so, ma spero almeno emerga un barlume di senso, un pensiero
sulla "big picture" metodologica. :-)
Ciao!

Vago ma ci siamo capiti, mi torna.

Vado un po' oltre.

Per ogni contesto definisco una gruppo di aggregati che mi servono per modellarlo. Può capitare che lo stesso aggregato possa essere condiviso tra 2 contesti? Si tratta di uno "shared kernel"?

thx

ema

 

Ciao a tutti,

mi si è accesa una piccola lampadina durante l'ultimo corso DDD a Londra.

Uno dei partecipanti, che stava già facendo DDD, è arrivato con una sfilza di domande provenienti dal team. Legate a "chi deve lanciare gli eventi", "come si devono mappare le relazioni gerarchiche" e così via. Cose che ricadono dell'ambito delle "domande più frequenti".

In generale, ho sempre pensato che fossero frequenti, perché ci sono aspetti su cui DDD non si pronuncia esplicitamente. Perché non c'è un "libro ufficiale su come fare DDD in Java" (e credo che questa asimmetria abbia aiutato la diffusione su .Net) e così via. Parlando della cosa con Eric era però evidente che lui non avesse voluto sbilanciarsi sulla parte pratica, perché il vero problema stava altrove. D'altro canto, DDD deve essere indipendente dalla tecnologia, quindi c'è anche il costo di manutenzione della documentazione di cui tenere conto.

Un punto però stava saltando fuori con una certa insistenza: DDD non è solo un insieme di pattern. Anzi, a dirla tutta, i pattern sono una naturale conseguenza dei principi. Se si applicano solo i pattern (cosa che leggendo solo la prima parte del libro, o il bignamino di InfoQ può capitare) si fa qualcosa che assomiglia a DDD, ma che DDD non è. Il punto chiave è molto più probabilmente riuscire a stabilire una "creative collaboration" con i domain expert. 

Sentendomi ripetere ancora una volta una domanda tecnica, mi sono chiesto: "Ma perché mi chiedono questa cosa?", cioè: io la risposta non la sapevo. :-) Se ho quel problema, ...provo. Se funziona sono a posto. Se non funziona sono comunque in un aggregato con poche dipendenze esterne, e non appena scopro qualcosa di meglio lo riscrivo. 

La cosa di cui mi sono reso conto è che in molti casi la domanda tecnica nasconde un'insicurezza di fondo. Che porta a voler cercare quanto prima una situazione sicura (ho fatto come dice il libro) anziché accettare il fatto di trovare una sensazione "tentativo" e di tenersi aperta la possibilità di cambiare. In realtà quello che serve non è la sicurezza di fare le cose giuste. Ma la tranquillità di poter sbagliare. Ed ovviamente di imparare dagli errori fatti.

Brando

--
Alberto Brandolini
Phone: +39-347-6005027

E-mail: alberto.brandolini@...

Web: http://albertobrandolini.wikidot.com
Company: http://www.avanscoperta.it
Blog: http://ziobrando.blogspot.com
Linkedin page: http://www.linkedin.com/in/brando

 

Ciao,

lavoro da alcuni con domain model finanziari per banche (su .NET).
Sono assolutamente d'accordo che ovviamente il punto fondamentale del DDD è stabilire una buona comunicazione con il domain expert.

Tuttavia, dopo tanti errori, noi abbiamo raccolto una serie di "pattern" modellativi che hanno mostrato di funzionare bene (nonché un enorme serie di anti-pattern che sembrano gran furbate sulle prime e risultano devastanti dopo due settimane)
Tali pattern, una volta condivisi hanno permesso di ridurre notevolmente la curva di apprendimento della metodologia.

Alla fine, in estrema sintesi, se il codice che usa il dominio non è "leggibile" dall'esperto, è sbagliato.

E' chiaro che essendo pattern "casalinghi" non hanno l'autorevolezza di un libro stampato (e solo la produttività concreta che hanno dimostrato ha reso possibile la loro diffuzione nella nostra azienda).

Purtroppo, di questi tempi, con commerciali che vendono sistematicamente al ribasso, la tranquillità di sbagliare da noi non c'è.

E senza questi pattern, di fatto, molti colleghi avrebbero probabilmente rifiutato nei fatti la metodologia in toto.

Senza capacità di rispondere anche su aspetti tecnici (magari ragionando insieme a chi pone un problema, cercando insieme soluzioni generali), si perde credibilità personale (che purtroppo spesso nella pratica, viene identificata con la credibilità e la validità della metodologia stessa).

D'altronde che cos'è la responsabilità se non la capacità di rispondere?

Devo dire comunque, che l'assenza di framework mainstream seriamente orientati al DDD e che non richiedano di essere combattuti, faciliterebbe.

La maggioranza degli sviluppatori (me compreso) preferisce le strade battute.
Personalmente tutte le volte che me ne discosto devo avere ottime ragioni per farlo.

E quando capita, mi rendo conto di quanto giovane sia la nostra "attività artigiana".
Lo sviluppo software, checché ne dicano i grandi vendor è appena alla preistoria...

Giacomo

2011/4/14 Alberto Brandolini <alberto.brandolini@...>

 

Ciao a tutti,

mi si è accesa una piccola lampadina durante l'ultimo corso DDD a Londra.

Uno dei partecipanti, che stava già facendo DDD, è arrivato con una sfilza di domande provenienti dal team. Legate a "chi deve lanciare gli eventi", "come si devono mappare le relazioni gerarchiche" e così via. Cose che ricadono dell'ambito delle "domande più frequenti".

In generale, ho sempre pensato che fossero frequenti, perché ci sono aspetti su cui DDD non si pronuncia esplicitamente. Perché non c'è un "libro ufficiale su come fare DDD in Java" (e credo che questa asimmetria abbia aiutato la diffusione su .Net) e così via. Parlando della cosa con Eric era però evidente che lui non avesse voluto sbilanciarsi sulla parte pratica, perché il vero problema stava altrove. D'altro canto, DDD deve essere indipendente dalla tecnologia, quindi c'è anche il costo di manutenzione della documentazione di cui tenere conto.

Un punto però stava saltando fuori con una certa insistenza: DDD non è solo un insieme di pattern. Anzi, a dirla tutta, i pattern sono una naturale conseguenza dei principi. Se si applicano solo i pattern (cosa che leggendo solo la prima parte del libro, o il bignamino di InfoQ può capitare) si fa qualcosa che assomiglia a DDD, ma che DDD non è. Il punto chiave è molto più probabilmente riuscire a stabilire una "creative collaboration" con i domain expert. 

Sentendomi ripetere ancora una volta una domanda tecnica, mi sono chiesto: "Ma perché mi chiedono questa cosa?", cioè: io la risposta non la sapevo. :-) Se ho quel problema, ...provo. Se funziona sono a posto. Se non funziona sono comunque in un aggregato con poche dipendenze esterne, e non appena scopro qualcosa di meglio lo riscrivo. 

La cosa di cui mi sono reso conto è che in molti casi la domanda tecnica nasconde un'insicurezza di fondo. Che porta a voler cercare quanto prima una situazione sicura (ho fatto come dice il libro) anziché accettare il fatto di trovare una sensazione "tentativo" e di tenersi aperta la possibilità di cambiare. In realtà quello che serve non è la sicurezza di fare le cose giuste. Ma la tranquillità di poter sbagliare. Ed ovviamente di imparare dagli errori fatti.

Brando

--
Alberto Brandolini
Phone: +39-347-6005027

E-mail: alberto.brandolini@...

Web: http://albertobrandolini.wikidot.com
Company: http://www.avanscoperta.it
Blog: http://ziobrando.blogspot.com
Linkedin page: http://www.linkedin.com/in/brando

 

Ciao Giacomo, e benvenuto!

Il giorno 14 aprile 2011 17:54, Giacomo Tesio <giacomo@...> ha scritto:

Tuttavia, dopo tanti errori, noi abbiamo raccolto una serie di "pattern" modellativi che hanno mostrato di funzionare bene (nonché un enorme serie di anti-pattern che sembrano gran furbate sulle prime e risultano devastanti dopo due settimane)
Tali pattern, una volta condivisi hanno permesso di ridurre notevolmente la curva di apprendimento della metodologia.

Alla fine, in estrema sintesi, se il codice che usa il dominio non è "leggibile" dall'esperto, è sbagliato.

Uno degli aspetti che volevo mettere in evidenza è proprio questo. Avete sperimentato, e mi sembra che la conseguenza sia una consapevolezza più profonda di "Eric nel libro ha detto di non fare questa cosa". 

E' chiaro che essendo pattern "casalinghi" non hanno l'autorevolezza di un libro stampato (e solo la produttività concreta che hanno dimostrato ha reso possibile la loro diffuzione nella nostra azienda).

Purtroppo, di questi tempi, con commerciali che vendono sistematicamente al ribasso, la tranquillità di sbagliare da noi non c'è.

Hai anche già indicato il problema. Se abbassi troppo gli spazi di manovra, di fatto stai ipotizzando il progetto in cui non puoi permetterti di sbagliare nulla. Ovvero una condizione perfetta per sbagliare e non poter correggere. Per certi versi simile alla partita dell'Inter di ieri sera.

E senza questi pattern, di fatto, molti colleghi avrebbero probabilmente rifiutato nei fatti la metodologia in toto.

... qui ti chiederei di espandere. Cosa avrebbero rifiutato, ed a favore di cosa?

Senza capacità di rispondere anche su aspetti tecnici (magari ragionando insieme a chi pone un problema, cercando insieme soluzioni generali), si perde credibilità personale (che purtroppo spesso nella pratica, viene identificata con la credibilità e la validità della metodologia stessa).

E' chiaro che la parte tecnica serve. Ma è anche vero che molto spesso gli aspetti vengono eccessivamente sovrapposti. Ricordo una discussione abbastanza accesa a Better Software l'anno scorso riguardo al fatto che il Coach dovesse dare anche una guida tecnica. Il ruolo del coach dovrebbe essere quello di far crescere il team, trovando i propri punti di forza. Essere anche una guida tecnica potrebbe essere una complicazione.

Però la risposta corretta è quella che suggerisci: ragionando insieme le soluzioni si trovano. E - per capirci - a me rispondere alle domande incasinate... piace. L'aspetto che mi inquieta a volte è la ricerca di "regole". 

D'altronde che cos'è la responsabilità se non la capacità di rispondere?

Ok, come classifichi l'assunzione di responsabilità di uno che ti dice: "ho fatto come dice il libro?". Io ci vedo un po' il riflesso di un ambiente che non tollera facilmente gli errori. Ho l'impressione che stiamo dicendo cose simili da angolazioni differenti.

Devo dire comunque, che l'assenza di framework mainstream seriamente orientati al DDD e che non richiedano di essere combattuti, faciliterebbe.

...intendevi la presenza?  

La maggioranza degli sviluppatori (me compreso) preferisce le strade battute.
Personalmente tutte le volte che me ne discosto devo avere ottime ragioni per farlo.

...beh se ho un nuovo problema, la strada battuta è un po' difficile. Non è che si vada a caccia della soluzione esplorativa "a prescindere", se con i pattern classici la cosa "fila", bene. Se ho un problema relativamente nuovo e mi trovo in difficoltà con quello che ho implementato... provo una soluzione alternativa.  

E quando capita, mi rendo conto di quanto giovane sia la nostra "attività artigiana".
Lo sviluppo software, checché ne dicano i grandi vendor è appena alla preistoria...

Questo decisamente, ma la crescita è veloce :-)

Tuttavia, dopo tanti errori, noi abbiamo raccolto una serie di "pattern" modellativi che hanno mostrato di funzionare bene (nonché un enorme serie di anti-pattern che sembrano gran furbate sulle prime e risultano devastanti dopo due settimane)
Tali pattern, una volta condivisi hanno permesso di ridurre notevolmente la curva di apprendimento della metodologia.

Alla fine, in estrema sintesi, se il codice che usa il dominio non è "leggibile" dall'esperto, è sbagliato.

Uno degli aspetti che volevo mettere in evidenza è proprio questo. Avete sperimentato, e mi sembra che la conseguenza sia una consapevolezza più profonda di "Eric nel libro ha detto di non fare questa cosa". 

Alla luce delle nostre sperimentazioni abbiamo anche compreso che il libro di Evans non è affatto "esaustivo" (sebbene FONDAMENTALE).
Prendiamo ad esempio la mutabilità di un valueobject. Nel libro si _consiglia_ di renderli immutabili: noi un paio di volte abbiamo pensato che fosse sensato allontanarsi da questo consiglio, con effetti devastanti di lì ad un mese.

Così come sulle referenze circolari fra entità (sconsigliate, ma non "vietate"), per fare esempi semplici che però hanno bruciato settimane di lavoro in refactoring.
Oppure la centralità di boundary context ben definiti ed in dipendenti a priori (cosa ben spiegata nel libro, ma forse senza la sufficiente enfasi, quasi che sia più importante del concetto di entità/value object, direi).

Siamo giunti alla conclusione che ogni volta che la rappresentazione del dominio fatica ad adottare questi pattern (ed altri pattern casalinghi) c'è da qualche parte un errore di comprensione del modello di business stesso.

E nell'ultimo anno, quando questo succede, riprendiamo la discussione dall'inizio con il domain expert.

Questo semplicemente perché abbiamo osservato che è più economico!

E' chiaro che essendo pattern "casalinghi" non hanno l'autorevolezza di un libro stampato (e solo la produttività concreta che hanno dimostrato ha reso possibile la loro diffuzione nella nostra azienda).

Purtroppo, di questi tempi, con commerciali che vendono sistematicamente al ribasso, la tranquillità di sbagliare da noi non c'è.

Hai anche già indicato il problema. Se abbassi troppo gli spazi di manovra, di fatto stai ipotizzando il progetto in cui non puoi permetterti di sbagliare nulla. Ovvero una condizione perfetta per sbagliare e non poter correggere. Per certi versi simile alla partita dell'Inter di ieri sera.

Vero, il rischio di degradare in tale condizione esiste (ed è pure capitato in un progetto).

Tuttavia abbiamo imparato così bene l'importanza del modello dominio che su quello cerchiamo di non sbagliare.
E se ci accorgiamo di un errore potenziale, fermiamo tutto (con sommo terrore e grande disapprovazione dei commerciali) e riprendiamo l'analisi con l'esperto di dominio.

Questi pattern "stringenti" servono quasi da cartina tornasole: se fatichiamo ad adottarli, capiamo che abbiamo frainteso qualcosa del modello stesso e cerchiamo subito un deeper insight.

 

E senza questi pattern, di fatto, molti colleghi avrebbero probabilmente rifiutato nei fatti la metodologia in toto.

... qui ti chiederei di espandere. Cosa avrebbero rifiutato, ed a favore di cosa?

Noi lavoriamo anche per l'industria e l'energia.
In questi ambiti, molto spesso le applicazioni che abbiamo sviluppato finora sono molto data driven.
Ed in effetti tipicamente i nostri dba dettano quasi legge! :-D

Alcuni programmatori che si sono trasferiti lo scorso anno dal settore energia alla finanza hanno opposto una certa resistenza ad allontanarsi da un modello DB -> servizi SOA (procedurali) -> GUI sostanzialmente rad.

Solo la enorme complessità dei problemi che si sono trovati davanti (come gestire le sessioni di consulenza mifid per i private banker di una grande banca) li ha convinti che un approccio del genere non funzionava (in tempi e qualità compatibili con l'esigenze del cliente).

 

Senza capacità di rispondere anche su aspetti tecnici (magari ragionando insieme a chi pone un problema, cercando insieme soluzioni generali), si perde credibilità personale (che purtroppo spesso nella pratica, viene identificata con la credibilità e la validità della metodologia stessa).

E' chiaro che la parte tecnica serve. Ma è anche vero che molto spesso gli aspetti vengono eccessivamente sovrapposti. Ricordo una discussione abbastanza accesa a Better Software l'anno scorso riguardo al fatto che il Coach dovesse dare anche una guida tecnica. Il ruolo del coach dovrebbe essere quello di far crescere il team, trovando i propri punti di forza. Essere anche una guida tecnica potrebbe essere una complicazione.

Però la risposta corretta è quella che suggerisci: ragionando insieme le soluzioni si trovano. E - per capirci - a me rispondere alle domande incasinate... piace. L'aspetto che mi inquieta a volte è la ricerca di "regole". 

Personalmente sono molto più critico rispetto alle "regole" di processo che ai pattern di modellazione.

Fin ora tutti i tentativi di rendere più Agile i processi di sviluppo del settore finanza sono falliti miseramente (contrariamente a quanto avviene nel settore industria, per esempio).
Se è evidente a tutti che il valore sta nelle persone che lavorano nel team, la complessità dei problemi che affrontiamo (e forse anche la dimensione degli applicativi che stiamo vendendo di recente) sfugge alle metodologie tanto decantate da altri.

Noi ci siamo trovati ad essere una specie di scatola nera nell'aziende: in ogni iterazione buttano dentro specifiche di altissimo livello -> rompiamo le balle al domain expert fin quando basta -> diamo dei tempi -> rispettiamo i tempi -> il cliente è soddisfatto.
Quando il management ha cercato di risparmiare sull'analisi di dominio, tutte le volte abbiamo finito per rifare il lavoro (in un caso ben tre volte!).

L'unico aspetto del processo che seguiamo sempre è l'assoluta priorità del dominio rispetto al resto (db, servizi, gui etc).
Fin quando non ci è _chiaro_ il dominio del problema non diamo nemmeno i tempi!

D'altronde che cos'è la responsabilità se non la capacità di rispondere?

Ok, come classifichi l'assunzione di responsabilità di uno che ti dice: "ho fatto come dice il libro?". Io ci vedo un po' il riflesso di un ambiente che non tollera facilmente gli errori. Ho l'impressione che stiamo dicendo cose simili da angolazioni differenti.

Mah.. ho la fortuna di lavorare in un azienda in cui abbiamo investito circa 20 mesi uomo per sviluppare un framework interno per sviluppare rapidamente GUI basate su domini fortemente tipizzati e molto complessi. Apparentemente follia pura!

Eppure è stata una decisione ben ponderata, perché i prodotti disponibili sul mercato non permettevano la produttività di cui avevamo bisogno.

Ho partecipato personalmente alla progettazione ed allo sviluppo di tale framework ed eravamo tutti coscienti (management incluso) dei rischi di tale percorso.
Non siamo mai stati "cazziati" per gli errori che abbiamo fatto (ed i conseguenti refactoring della codebase che abbiamo causato).

Ma credo sia il mercato a non tollerare certi errori.
Ogni banca da cui andiamo ha dei processi mastodontici di approvazione degli applicativi!

Ogni deploy è vissuto come "che bello, oggi andiamo al ministero"!
E la concorrenza è spietata. Noi puntiamo all'eccellenza (da ben prima del mio arrivo in azienda), ma abbiamo dovuto fare i conti con una concorrenza basata sul prezzo (e sui tempi di consegna).

Siamo tutti coscienti di essere stati molto fortunati ad uscirne vivi (e fortunatamente arzilli :-D).

 

Devo dire comunque, che l'assenza di framework mainstream seriamente orientati al DDD e che non richiedano di essere combattuti, faciliterebbe.

...intendevi la presenza?  

Sì, scusa. Tutto ciò che trovo in giro è ben lungi dalle nostre esigenze (in finanza).

 

La maggioranza degli sviluppatori (me compreso) preferisce le strade battute.
Personalmente tutte le volte che me ne discosto devo avere ottime ragioni per farlo.

...beh se ho un nuovo problema, la strada battuta è un po' difficile. Non è che si vada a caccia della soluzione esplorativa "a prescindere", se con i pattern classici la cosa "fila", bene. Se ho un problema relativamente nuovo e mi trovo in difficoltà con quello che ho implementato... provo una soluzione alternativa.  

Alcune volte le strade battute sono sbagliate.
Ti potrei fare un breve elenco di pattern battutissimi, ma che abbiamo dovuto abbiamo dovuto abbandonare a ragion veduta.

Un esempio sempre sconcertante quando condividiamo il nostro approccio con i colleghi del settore energia: l'event EventBroker è un (anti)pattern per disaccoppiare dagli eventi .NET.
_Sul domain model_ è una soluzione ad un sintomo. Ma abbiamo compreso che genera più problemi di quanti non ne risolva.

Così abbiamo dovuto risalire al problema vero e risolverlo alla base.

 

E quando capita, mi rendo conto di quanto giovane sia la nostra "attività artigiana".
Lo sviluppo software, checché ne dicano i grandi vendor è appena alla preistoria...

Questo decisamente, ma la crescita è veloce :-)

Non sono così d'accordo. Volendo fare un paragone con l'architettura classica, siamo ancora a Micene, intorno al 1400 A.C.

Giacomo

... ma la domanda ora è: "Dove siete stati tutto questo tempo?" :-) 

Noi lavoriamo anche per l'industria e l'energia.

In questi ambiti, molto spesso le applicazioni che abbiamo sviluppato finora sono molto data driven.
Ed in effetti tipicamente i nostri dba dettano quasi legge! :-D

Un mondo diverso è possibile... 

Il mondo bancario in effetti è particolarmente ingessato. Ho l'impressione che sia anche la conseguenza di un mercato sostanzialmente non competitivo, perché siamo in un settore in cui si potrebbe fare "immensamente meglio" ma in cui ho visto solo situazioni che andavano "un pochino meglio". Il discorso sarebbe lunghissimo, ma la sintesi è "troppa (inutile) politica".

Però ho l'impressione che tu abbia qualcosa di interessante e di specifico da dire anche in sede di processo. Oppure semplicemente mi hai incuriosito.

P.S. hai dato un'occhiata a questo? http://domainlanguage.com/ddd/whirlpool/ 

Noi ci siamo trovati ad essere una specie di scatola nera nell'aziende: in ogni iterazione buttano dentro specifiche di altissimo livello -> rompiamo le balle al domain expert fin quando basta -> diamo dei tempi -> rispettiamo i tempi -> il cliente è soddisfatto.
Quando il management ha cercato di risparmiare sull'analisi di dominio, tutte le volte abbiamo finito per rifare il lavoro (in un caso ben tre volte!).

Glielo avete fatto pesare con adeguato sarcasmo? ;-) 

Dal punto di vista "lean" mi viene da chiedere: "Qual è il valore aggiunto di questi processi?". Il problema è che ad essere sbagliati sono loro. E spesso non puoi risolvere un problema con gli stessi strumenti con cui il problema è stato creato. O (più pessimisticamente) con gli stessi uomini.

In realtà il mercato è dominato dagli errori, e dalle strategie tese a parsi il c***, non ad evitarli.

 

Ogni deploy è vissuto come "che bello, oggi andiamo al ministero"!
E la concorrenza è spietata. Noi puntiamo all'eccellenza (da ben prima del mio arrivo in azienda), ma abbiamo dovuto fare i conti con una concorrenza basata sul prezzo (e sui tempi di consegna).

A volte quello che manca è la sicurezza di essere sulla buona strada. La tranquillità di poter dire: "Fate pure, fra 2 anni avrete una code base non mantenibile ed il nostro prezzo per fare la stessa cosa sarà il doppio, perché dovremo togliere il vecchio E rifarlo per bene". 

Siamo tutti coscienti di essere stati molto fortunati ad uscirne vivi (e fortunatamente arzilli :-D).

Non è fortuna. 

 

Devo dire comunque, che l'assenza di framework mainstream seriamente orientati al DDD e che non richiedano di essere combattuti, faciliterebbe.

...intendevi la presenza?  

Sì, scusa. Tutto ciò che trovo in giro è ben lungi dalle nostre esigenze (in finanza).

Avete avuto modo di provare Naked Objects (ma è zona Java, se non vado errato)?  

Un esempio sempre sconcertante quando condividiamo il nostro approccio con i colleghi del settore energia: l'event EventBroker è un (anti)pattern per disaccoppiare dagli eventi .NET.
_Sul domain model_ è una soluzione ad un sintomo. Ma abbiamo compreso che genera più problemi di quanti non ne risolva.

Nelle ultime evoluzioni di DDD, Eric ha spinto notevolmente verso una comunicazione basata sui Domain Event, ma al suo livello sono estremamente disaccoppiati dall'infrastruttura tecnologica. Mi pare che tu stia parlando di una cosa differente. Ed in questo caso concordo con te in pieno: le soluzioni tecnologiche attirano i programmatori come le mosche, ma non spingono mai ad affrontare la complessità del problema. Anche perché i problemi veri si fa fatica a spiegarli in una demo.

 

... mi hai messo decisamente di buon umore :-)

Brando

 

Ciao a tutti!

Un paio di settimane fa a Portland (ME) si è svolto il DDDSummit, un piccolo raduno di "praticanti" di Domain Driven Design: per 3 giorni una decina di professionisti del settore si sono ritrovati per discutere cosa si intenda oggi per DDD, quale sia il valore e le prospettive e ...quant'altro potesse emergere dalla situazione "metto 10 teste nella stessa stanza e  ne uscirà fuori qualcosa di buono" :-)

Ne è uscita un'immagine di DDD un po' diversa da quella che si può trarre da una lettura del libro. Il valore principale di DDD sta infatti nella formalizzazione di dominii complessi e/o inesplorati. In altre parole: Capire (con la C maiuscola) insieme al business quali sono i nodi specifici del dominio in cui andiamo ad operare. Pare scontato, ma non lo è affatto: molte aziende hanno un'idea piuttosto vaga di quale sia il loro reale core business, ed altre non hanno software in grado di garantire loro un vantaggio competitivo. I dominii non ancora consolidati sono l'area in cui DDD può fornire il massimo del valore, in quanto mix di processo/architettura/principi specializzato sull'esplorazione.

E il codice più mantenibile? Ed il disaccoppiamento sullo sviluppo in larga scala? Tutto ancora valido. Semplicemente, l'esperienza dei colleghi ha messo in luce che il primo e più importante risultato della Creative Collaboration, costruita attorno allo Ubiquitous Language è l'emersione di un modello di business chiaro anche ai ruoli business. Risultato che per molte aziende rappresenta un valore più grande e più immediato rispetto a quanto ottenibile ragionando "solo" in ottica di codice.

Viene per certi versi messo in second'ordine l'aspetto puramente architetturale. Di fatto siamo arrivati a parlare di "Supporting Architecture" includendo tra queste, sia il modello proposto nel "libro azzurro" sia l'architettura esagonale di Cockburn (con la quale ci sono notevoli punti in comune), sia le nuove tendenze quali CQRS ed Event Sourcing.

Brando

--
Alberto Brandolini
Phone: +39-347-6005027

E-mail: alberto.brandolini@...
Twitter: @ziobrando

Company: http://www.avanscoperta.it
Blog: http://ziobrando.blogspot.com
Linkedin page: http://www.linkedin.com/in/brando

Ciao Uberto, e benvenuto!

devo confessare che io invece non sono ancora riuscito a completare il GOOS. L'approccio di Freeman e Pryce mi piace un sacco, e ci sono un sacco di cose che tornano, ...ma non posso ancora dirmi completamente GOOSiano.

Quanto agli aspetti delle side effect free functions e dei Value Object, confermo che ci sono un sacco di punti di contatto: l'effetto che sto sperimentando su di me è che anche i test unitari (l'altra strada che sto battendo al momento è quella di BDD-Cucumber) tendono a migliorare notevolmente la loro leggibilità.

L'effetto che mi stai descrivendo mi rammenta qualcosa di cui parlò Matteo Vaccari all'ultima Codemotion, dove in effetti faceva a meno delle entity. Se testi per "fare" qualcosa, la maggior parte dei dati ...non serve. E' solo trasferimento di informazione. Dal punto di vista del comportamento è quasi irrilevante.

Io in questo momento sto seguendo un percorso diverso ma probabilmente con qualche analogia di fondo:

- forte disaccoppiamento degli aggregati

- comunicazione ad eventi tra gli aggregati

La Entity nel mio aggregato, raramente nasce dai dati. A volte li aggiungo alla fine. Per me è sostanzialmente una macchina a stati ed un contenitore di invarianti. Non so se il mio approccio di Entity come macchina a stati (non sempre ...spesso) torna con il tuo, ma ho l'impressione che stiamo vedendo qualcosa di simile.

.A questa cosa aggiungo il recente tentativo di applicare il paradigma alla Greg Young di testare con qualcosa di simile a

Given [events]*

When [command]

Then [event]

in un contesto di questo genere, il mio aggregato finisce per diventare un cosino molto molto semplice, con l'unico aggravio di complicazione di dover gestire un set di eventi in ingresso che arrivano su canali asincroni. Non banale all'inizio, ma dal punto di vista concettuale è piuttosto interessante. Ed i componenti sono "pluggabili" in maniera molto più elegante.

Tornando allo specifico della tua domanda, non so se ci sia un ruolo esplicito per gli Agent che citi. Ho classi che fanno, a volte sono locali all'aggregato, a volte sono comuni ed allora li promuovo a Service. Ma in generale la presenza di molti Service ...a me spesso puzza come uno smell di un modello anemico nascosto da qualche parte.

No sembra essere il tuo caso, però.

E' anche vero che se hai una componente del dominio senza troppa complessità, l'anagrafe clienti ad esempio, ...non ti metti a farci DDD sopra. Buona parte delle Entity che vedo in giro sono "ho cominciato DDD da qui perché questa è la prima cosa che ho capito dal libro"...

Brando

Il giorno 09 agosto 2011 14:34, ubertob <uberto@...> ha scritto:

 

Ciao a tutti,

mi chiamo Uberto e lavoro come SW arch/team leader in una grossa telco a Dusseldorf (quella rossa :)).
Colpevolvemente non sapevo dell'esistenza di questa ML, grazie ZioBrando! :)

Vengo rapidamente al punto. Essendo appassionato di buon codice avevo letto DDD la prima volta nel 2005, l'ho riletto appena arrivato qui in Germania nel 2007 e lo sto rileggendo oggi per la terza volta.

Nel frattempo il mio modo di scrivere codice si e' molto evoluto, sia per l'esperienza vissuta qui (2 grossi progetti Java) sia per libri che ho letto, in particolare GOOS e linguaggi che ho imparato Haskell e Lisp in primis.

Mi sono accorto che diverse cose che "ho imparato" recentemente erano gia' descritte li' dettagliatamente (funzioni senza sideeffect, value object immutabili) ma non me ne ero accorto la prima volta che l'avevo letto.

Riguardo alla sua distinzione tra ValueObject, Entity, Service invece recentemente mi sono reso conto che uso sempre meno Entities e sempre piu' Services.
Soprattutto non uso piu' Entities per mappare oggetti del dominio (Customer) ma piuttosto stati tecnici (Controller, Cache, ConnectionPool).
Per il manipolare il dominio invece uso degli "Agent" (CustomerPersister, CustomerRenderer) che in pratica non sono altro che classi che offrono uno o piu' Service (di solito uno comunque). Gli Agent non hanno uno stato interno, quindi non importa a quale Agent chiedo quale Service, la risposta dipende chiaramente dallo stato del sistema in generale ma non dalla storia del singolo agent. Se gli Agent serve usano Entity per interrogare lo stato generale del sistema.
Se serve posso postare un po' di nostro codice "offuscato".

Da un punto di vista tecnico nessuno conosce la classe degli Agent e delle Entity ma solo la loro interfaccia, che non espone nulla di stati interni o parziali.

Perche' facciamo questo? Beh la risposta breve e' che questo meta-design ci permette di aumentare considerevolmente la produttivita' mantenendo il codice leggibile e completamente testato. Trattandosi di progetti di diverse kloc sono discretamente fiero che non siano ancora legacy ma vivi e reattivi. :)

Mi chiedevo se nel mondo DDD c'e' qualcunaltro che si sta muovendo in questa direzione.
Che ripeto non e' una cosa che ho cercato ma e' un qualcosa che mi sta venendo fuori "da solo" dal TDD. :)

ciao

Uberto

ps. ho presentato uno dei nostri progetti e come usiamo gwt qui: http://www.slideshare.net/ubertobarbini/develop-gwt-application-in-tdd

--
Alberto Brandolini
Phone: +39-347-6005027

E-mail: alberto.brandolini@...
Twitter: @ziobrando

Company: http://www.avanscoperta.it
Blog: http://ziobrando.blogspot.com
Linkedin page: http://www.linkedin.com/in/brando

Ciao Uberto, e benvenuto!

devo confessare che io invece non sono ancora riuscito a completare il GOOS. L'approccio di Freeman e Pryce mi piace un sacco, e ci sono un sacco di cose che tornano, ...ma non posso ancora dirmi completamente GOOSiano.

Quanto agli aspetti delle side effect free functions e dei Value Object, confermo che ci sono un sacco di punti di contatto: l'effetto che sto sperimentando su di me è che anche i test unitari (l'altra strada che sto battendo al momento è quella di BDD-Cucumber) tendono a migliorare notevolmente la loro leggibilità.

L'effetto che mi stai descrivendo mi rammenta qualcosa di cui parlò Matteo Vaccari all'ultima Codemotion, dove in effetti faceva a meno delle entity. Se testi per "fare" qualcosa, la maggior parte dei dati ...non serve. E' solo trasferimento di informazione. Dal punto di vista del comportamento è quasi irrilevante.

Io in questo momento sto seguendo un percorso diverso ma probabilmente con qualche analogia di fondo:

- forte disaccoppiamento degli aggregati

- comunicazione ad eventi tra gli aggregati

La Entity nel mio aggregato, raramente nasce dai dati. A volte li aggiungo alla fine. Per me è sostanzialmente una macchina a stati ed un contenitore di invarianti. Non so se il mio approccio di Entity come macchina a stati (non sempre ...spesso) torna con il tuo, ma ho l'impressione che stiamo vedendo qualcosa di simile.

.A questa cosa aggiungo il recente tentativo di applicare il paradigma alla Greg Young di testare con qualcosa di simile a

Given [events]*

When [command]

Then [event]

in un contesto di questo genere, il mio aggregato finisce per diventare un cosino molto molto semplice, con l'unico aggravio di complicazione di dover gestire un set di eventi in ingresso che arrivano su canali asincroni. Non banale all'inizio, ma dal punto di vista concettuale è piuttosto interessante. Ed i componenti sono "pluggabili" in maniera molto più elegante.

Tornando allo specifico della tua domanda, non so se ci sia un ruolo esplicito per gli Agent che citi. Ho classi che fanno, a volte sono locali all'aggregato, a volte sono comuni ed allora li promuovo a Service. Ma in generale la presenza di molti Service ...a me spesso puzza come uno smell di un modello anemico nascosto da qualche parte.

No sembra essere il tuo caso, però.

E' anche vero che se hai una componente del dominio senza troppa complessità, l'anagrafe clienti ad esempio, ...non ti metti a farci DDD sopra. Buona parte delle Entity che vedo in giro sono "ho cominciato DDD da qui perché questa è la prima cosa che ho capito dal libro"...

 

Ciao Uberto!

Non mi è molto chiaro in che modo usiate le entità per mappare stati tecnici.

Un'entità è un oggetto identificabile nel tempo e presente nel linguaggio condiviso fra esperti di dominio e sviluppatori: magari il vostro applicativo gestisce oggetti virtuali, come cache o application pool e tutto tornerebbe perfettamente, ma non mi è chiaro cosa intendessi allora per stati tecnici.

Anche io ho imparato (da Haskell, più che da Evans) il valore dell'immutabilità, però molte entità continuo a vedermele mutabili, anche se solo per un singolo field.

Inoltre, quando modello, mi preoccupo che un qualunque collega che non sa niente del contesto in esame e non abbia partecipato alle riunioni con l'esperto del dominio, leggendo le interfacce e la documentazione del codice capisca come funziona il dominio e come si usa (possibilmente senza andare a guardare gli unit tests, a cui comunque anche noi diamo molto peso, cercando di raggiungere almeno il 100% di coverage). 

Come effetto però noi abbiamo una fortissima tipizzazione e gerarchie di oggetti molto basse: all'inizio tutte le entità derivavano da uno storico IBusinessObject, ma per fortuna con sangue sudore e lacrime ce ne siamo ormai liberati per il 95% negli applicativi sviluppati in DDD. Questo ci permette di non violare il Liskow principle (e la definizione di contesti molto ben definiti ci permette di ridurre i rischi di violare l'OCP e il SRP).

Il sistema di agenti che descrivi mi sembra pericoloso quanto il nostro vecchio IBusinessObject, che permetteva di vedere tutto nello stesso modo (molto CRUD) ma ti faceva completamente perdere il dettaglio (ovvero il business effettivo che le nostre classi modellavano). Agent mi sembra sull'estremo opposto, mi sembra incapsulare il solo comportamento di business, ma senza linea di continuita (ovvero senza identità/entità) e senza stato (non so se mi spiego).

Non conosco GOOS (mai sentito!!! :-O !!!), ma anche noi usiamo molto i mocks sia per testare il dominio che ciò che ne dipende (in particolare i presenter, ma anche gli script di importazione dati per esempio) ed abbiamo adottato da circa un anno una convenzione di naming degli unit test che descrivevo qui (in realtà, alcuni miei colleghi già la adottavano da prima... io sono sempre l'ultimo a sapere le cose! :-D).

PS: Una considerazione importante: IBusinessObject si rivela distruttivo quando ci SERVE che gli sviluppatori parlino la stessa lingua degli esperti di dominio (e degli utenti), ovvero tipicamente quando lavoriamo sul core business del cliente (e il cliente, del suo core business, ne sa :-D). 

Al constrario, quando il cliente parla in termini di tabelle e trigger (cosa che ci succede talvolta in industria ed energia) o quando gli applicativi sviluppati si occupano sostanzialmente di analisi dati (molti nostri applicativi sono tool di data mining e business intelligence avanzata, ci chiamiamo Operational Research System non a caso), diventa veramente utile e produttivo. 

E' possibile che voi vi troviate in una situazione simile, sebbene simmetricamente opposta?

 

2011/8/9 Giacomo Tesio <giacomo@...>

 

Ciao Uberto!

Non mi è molto chiaro in che modo usiate le entità per mappare stati tecnici.

Un'entità è un oggetto identificabile nel tempo e presente nel linguaggio condiviso fra esperti di dominio e sviluppatori: magari il vostro applicativo gestisce oggetti virtuali, come cache o application pool e tutto tornerebbe perfettamente, ma non mi è chiaro cosa intendessi allora per stati tecnici.

ok per entity intendevo "oggetto con stato interno modificabile". Lasciando stare il caso di stati tecnici negli adapter che poi non mi interessa, parlando del dominio ho visto che e' molto raro che mi serva una Entity.
Per esempio in GOOS si fa l'esempio di un sistema di aste online, allora e' chiaro li' che mi serve un oggetto con lo stato dell'asta corrente (aperta, chiusa, vincendo, perdendo). Pero' e' un caso raro.

Anche io ho imparato (da Haskell, più che da Evans) il valore dell'immutabilità, però molte entità continuo a vedermele mutabili, anche se solo per un singolo field.

mi fai qualche esempio? come mai ti serve un field mutabile?
 

Inoltre, quando modello, mi preoccupo che un qualunque collega che non sa niente del contesto in esame e non abbia partecipato alle riunioni con l'esperto del dominio, leggendo le interfacce e la documentazione del codice capisca come funziona il dominio e come si usa (possibilmente senza andare a guardare gli unit tests, a cui comunque anche noi diamo molto peso, cercando di raggiungere almeno il 100% di coverage). 

almeno il 100% signica che lo superate spesso? :)))
sottoscrivo in pieno, ma preferisco che tutti guardino gli UT prima di lavorare su un oggetto nuovo cosi' se ci sono malintesi (nei test o nell'interfaccia) si possono correggere subito.
 

Come effetto però noi abbiamo una fortissima tipizzazione e gerarchie di oggetti molto basse: all'inizio tutte le entità derivavano da uno storico IBusinessObject, ma per fortuna con sangue sudore e lacrime ce ne siamo ormai liberati per il 95% negli applicativi sviluppati in DDD. Questo ci permette di non violare il Liskow principle (e la definizione di contesti molto ben definiti ci permette di ridurre i rischi di violare l'OCP e il SRP).

Condivido. Poche classi astratte e gerarchie al massimo a 2 livelli.
<rant>
Sono anche diventato molto freddo nei confronti del SOLID. Ho visto delle porcate immonde giustificate con SRP (godclass) e OCP (gerarchie infinite). Liskow non lo capisce nessuno, per DI pensano di essere a posto usando Sprint e la IS che forse e' la piu' importante delle 5 non la usa nessuno. E Demeter non e' neppure citato.
</rant>
 

Il sistema di agenti che descrivi mi sembra pericoloso quanto il nostro vecchio IBusinessObject, che permetteva di vedere tutto nello stesso modo (molto CRUD) ma ti faceva completamente perdere il dettaglio (ovvero il business effettivo che le nostre classi modellavano). Agent mi sembra sull'estremo opposto, mi sembra incapsulare il solo comportamento di business, ma senza linea di continuita (ovvero senza identità/entità) e senza stato (non so se mi spiego).

 

Mmmh non ti seguo. Lo stato cerco di toglierlo apposta, lo considero un vantaggio visto che il 90% di bugs derivano da stati mal compresi. 

L'identita' (che poi deriva dallo stato) era un altra causa di mal di testa felicemente eliminata.
"senza linea di continuita'" --> non sono sicuro di averlo capito.
Il risultato come dici tu e' avere "il solo modello di business" senza cercare di modellare oggetti reali con oggetti 1 a 1.
Mi spiego, se faccio un sofware per muovere petroliere non e' che ho bisogno per forza della classe OilTanker come un entity con stato mutevole. Preferisco avere oggetti immutabili di tipo OilTankerSituation ed ogni volta che ho nuove informazioni sulla posizione o sul carico del mio oilTanker un qualche agent ritornera' una nuova instanza aggiornata, magari con il timestamp della rilevazione.

Questo comunque e' un esempio che ho fatto ora al volo, non dico che sia il sistema migliore, solo che mi sto trovando benissimo.

...

PS: Una considerazione importante: IBusinessObject si rivela distruttivo quando ci SERVE che gli sviluppatori parlino la stessa lingua degli esperti di dominio (e degli utenti), ovvero tipicamente quando lavoriamo sul core business del cliente (e il cliente, del suo core business, ne sa :-D). 

Al constrario, quando il cliente parla in termini di tabelle e trigger (cosa che ci succede talvolta in industria ed energia) o quando gli applicativi sviluppati si occupano sostanzialmente di analisi dati (molti nostri applicativi sono tool di data mining e business intelligence avanzata, ci chiamiamo Operational Research System non a caso), diventa veramente utile e produttivo. 

E' possibile che voi vi troviate in una situazione simile, sebbene simmetricamente opposta?

secondo me quando il cliente parla di tabelle e di trigger siamo fuori dal DDD, e se proprio vuole gli consiglio VB o qualche RAD. :)

Da noi il cliente parla solo per UC utente, piuttosto la seccatura sono gli architetti enterprise... :)

 

Ciao Uberto...

 

in realtá c'é qualche altro punto di contatto interessante.

 

Se ragioni in termini di Eventi, il contenuto informativo, i "dati" per intenderci. Stanno sostanzialmente negli eventi. Gli aggregati gestiscono le transizioni di stato in risposta agli eventi, ma le transizioni di stato dentro in confini dell'aggregato le gestisci come ti pare...salvo buttare fuori un evento al termine della trasformazione.

 

C'é un pezzo di ES/CQRS che non ho avuto modo di approfondire, che probabilmente ha punti in comune con quello che stai vedendo te. Penso soprattutto al tuo CustomerRenderer. La trasformazione dai dati in ingresso (comandi o eventi) ai dati in uscita View é gestita in maniera asincrona, spesso prepopolando tabelle o viste che poi vengono sparate "secche" in presentation senza passare dal Domain Model. Ho l'impressione che quello che avviene lí non sia molto diverso da quello che avviene nel tuo renderer. Cambia il momento in cui viene invocato, peró.

 

Per quanto riguarda i persister, io é da un po' che ho ricominciato a ragionare senza persistenza. Mi faccio i repository, ma in realtá li mocko. Alla fine non c'é molto. E posso decidere abbastanza tardi se andare su SQL o noSQL, etc.

L'identita' (che poi deriva dallo stato) era un altra causa di mal di testa felicemente eliminata.
"senza linea di continuita'" --> non sono sicuro di averlo capito.
Il risultato come dici tu e' avere "il solo modello di business" senza cercare di modellare oggetti reali con oggetti 1 a 1.
Mi spiego, se faccio un sofware per muovere petroliere non e' che ho bisogno per forza della classe OilTanker come un entity con stato mutevole. Preferisco avere oggetti immutabili di tipo OilTankerSituation ed ogni volta che ho nuove informazioni sulla posizione o sul carico del mio oilTanker un qualche agent ritornera' una nuova instanza aggiornata, magari con il timestamp della rilevazione.

In una situazione di questo genere io probabilmente finirei per avere un'aggregate root (Entity) che ha il ruolo di responsabile dell'identità. In caso di variazioni dello stato l'implementazione che di solito mi viene più naturale è lo State Pattern, in cui gli State sarebbero con ogni probabilità dei VO immutabili.

In altri casi, lo stato può essere derivato dall'avere soddisfatto determinate Specification. Ma in questo caso non è detto che la specification si porti dietro il comportamento, è fondamentalmente un modo più elegante di definire dei predicati.

Nell'interpretazione di Niclas Hedman (co-progettista di Qi4J insieme a Rickard Oberg) una Entity può essere ridotta ad un'identità ed una collezione di VO. Non è così lontano da quanto state dicendo voi.

 

<rant>

Quando il cliente parla di tabelle e trigger, se sono di buon umore cerco di accendere l'iPod. Disegnando quindi nervosamente su un foglio di carta navi che si scontrano con iceberg, esplosioni, corpi dilaniati, avvoltoi che se ne cibano, diavoli con il forcone ed altre amenità del genere. Poi chiedo: "come lo testate?"

</rant>

 

Da noi il cliente parla solo per UC utente, piuttosto la seccatura sono gli architetti enterprise... :)

Quelli che dicono che "tutto deve essere [stronzata del giorno]" ? ;-) 

...li adoro.