Workshop di assoluto interesse, che pur trattando un argomento complesso, è riuscito a darci degli ottimi input da cui partire per approfondire quanto visto.
Nei:
- c'era troppo poco tempo per il numero di persone partecipanti. Sarebbe stato utile approfondire un po' di più e completare con più cura l'esperienza.
- la sala era inadatta in quanto troppo dispersiva.
Sono rimasto molto colpito da questo Workshop. Ci ha dimostrato come in poco tempo si possa, partendo dagli eventi di un business, arrivare ad avere una idea abbastanza chiara del dominio. La concentrazione dell'analisi è stata fatta esclusivamente sul comportamento che l'applicazione, senza mai tirare in ballo "il dato". I tantissimi spunti, il solito mitico @ziobrando e gli attivi e curiosi partecipanti hanno reso questo Workshop il miglior evento della giornata.
Avevo una "pila" di obiettivi bella alta per questo workshop, qualche messaggio è andato a segno, mentre qualche altro ha avuto qualche difficoltà in più. In particolare, pur essendomi portato tutta una cartoleria da casa, avevo ipotizzato di poter stare al centro, vedendo due o tre gruppi di lavoro. Lavorando nel corridoio avevamo sì a disposizione una lunga superficie liscia, ma i gruppi hanno lavorato più isolati ed io ho perso un po' di visione d'insieme.
Riassumo un po' dei takeaways:
- se vogliamo modellare non c'è constraint che tenga: rotolo di carta e rotolo di scotch e possiamo farlo dovunque.
- i dev "godono" ad speculare su dominii immaginari. L'esperto di domino era presente e tutti i team inventavano cose che non c'erano nel dominio. Le domande all'esperto erano il piano B, o C.
- imporre un ordine dall'inizio può essere una strategia perdente. La prima esplorazione è caotica: prima raccogliamo i dati e poi capiamo che forma hanno. Lo spazio a volte impone dei vincoli, ma a volte siamo noi ad imporli.
- Eventi e Comandi ci permettono di evidenziare dove sono i nodi di comportamento del sistema. I "dati" non sono necessariamente una parte chiave.
- Questo approccio di modellazione va al bacio con DDD, ma è estremamente utile anche come modellazione a se stante. Non di rado si intraprende lo sviluppo di sistemi complessi senza avere chiaro il quadro generale.
- Realizzare un modello complesso può essere decisamente economico. Non lo si fa perché ci vuole troppo tempo. È falso. E capire come funziona esattamente un business si ripaga in tempi estremamente brevi. Quante pagine insensate ci siamo risparmiati?
- Modellare gli aggregati partendo dai dati non è necessariamente una strategia vincente, anzi.
- Ci sono più modelli all'interno del sistema, e più linguaggi. Se rendiamo evidente la possibilità di queste ambiguità la possiamo dominare.
Brando, la prossima volta mi porto i pattini ! ;-) Scherzi a parte, nonostante la conformazione della sala ci abbia remato contro, la riuscita é stata ottima a mio avviso; forse, aver avuto ancora un po' di tempo a disposizione avrebbe permesso di fissare meglio alcuni concetti che solo all'ultimo round iniziavano ad emergere dai partecipanti. Bel workshop, grazie !
Comments
Comments are closed.
Workshop di assoluto interesse, che pur trattando un argomento complesso, è riuscito a darci degli ottimi input da cui partire per approfondire quanto visto.
Nei:
- c'era troppo poco tempo per il numero di persone partecipanti. Sarebbe stato utile approfondire un po' di più e completare con più cura l'esperienza.
- la sala era inadatta in quanto troppo dispersiva.
Sono rimasto molto colpito da questo Workshop. Ci ha dimostrato come in poco tempo si possa, partendo dagli eventi di un business, arrivare ad avere una idea abbastanza chiara del dominio. La concentrazione dell'analisi è stata fatta esclusivamente sul comportamento che l'applicazione, senza mai tirare in ballo "il dato". I tantissimi spunti, il solito mitico @ziobrando e gli attivi e curiosi partecipanti hanno reso questo Workshop il miglior evento della giornata.
Avevo una "pila" di obiettivi bella alta per questo workshop, qualche messaggio è andato a segno, mentre qualche altro ha avuto qualche difficoltà in più. In particolare, pur essendomi portato tutta una cartoleria da casa, avevo ipotizzato di poter stare al centro, vedendo due o tre gruppi di lavoro. Lavorando nel corridoio avevamo sì a disposizione una lunga superficie liscia, ma i gruppi hanno lavorato più isolati ed io ho perso un po' di visione d'insieme.
Riassumo un po' dei takeaways:
- se vogliamo modellare non c'è constraint che tenga: rotolo di carta e rotolo di scotch e possiamo farlo dovunque.
- i dev "godono" ad speculare su dominii immaginari. L'esperto di domino era presente e tutti i team inventavano cose che non c'erano nel dominio. Le domande all'esperto erano il piano B, o C.
- imporre un ordine dall'inizio può essere una strategia perdente. La prima esplorazione è caotica: prima raccogliamo i dati e poi capiamo che forma hanno. Lo spazio a volte impone dei vincoli, ma a volte siamo noi ad imporli.
- Eventi e Comandi ci permettono di evidenziare dove sono i nodi di comportamento del sistema. I "dati" non sono necessariamente una parte chiave.
- Questo approccio di modellazione va al bacio con DDD, ma è estremamente utile anche come modellazione a se stante. Non di rado si intraprende lo sviluppo di sistemi complessi senza avere chiaro il quadro generale.
- Realizzare un modello complesso può essere decisamente economico. Non lo si fa perché ci vuole troppo tempo. È falso. E capire come funziona esattamente un business si ripaga in tempi estremamente brevi. Quante pagine insensate ci siamo risparmiati?
- Modellare gli aggregati partendo dai dati non è necessariamente una strategia vincente, anzi.
- Ci sono più modelli all'interno del sistema, e più linguaggi. Se rendiamo evidente la possibilità di queste ambiguità la possiamo dominare.
Ho caricato le slides con un po' di note di accompagnamento.... http://www.slideshare.net/ziobrando/event-based-modeling-iad-2012-15371656
Brando, la prossima volta mi porto i pattini ! ;-) Scherzi a parte, nonostante la conformazione della sala ci abbia remato contro, la riuscita é stata ottima a mio avviso; forse, aver avuto ancora un po' di tempo a disposizione avrebbe permesso di fissare meglio alcuni concetti che solo all'ultimo round iniziavano ad emergere dai partecipanti. Bel workshop, grazie !