• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
DDD 2011 - Dove Desideriamo Dirigerci
 

DDD 2011 - Dove Desideriamo Dirigerci

on

  • 1,423 views

La mia presentazione sull'evoluzione di DDD dall'uscita del libro nel 2004 ad oggi. Presentata al DDD-Day, in italiano.

La mia presentazione sull'evoluzione di DDD dall'uscita del libro nel 2004 ad oggi. Presentata al DDD-Day, in italiano.

Statistics

Views

Total Views
1,423
Views on SlideShare
1,377
Embed Views
46

Actions

Likes
3
Downloads
38
Comments
2

2 Embeds 46

http://lanyrd.com 43
http://a0.twimg.com 3

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

12 of 2 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \n
  • \n
  • And that’s the company I started one year ago.\n
  • Cominciamo guardando indietro. A dove eravamo. Il libro DDD è uscito nel 2004 e la sua gestazione è durata quattro anni. Molte delle considerazioni presenti nel libro sono espresse tenendo conto del contesto dell’epoca.\n
  • Questo è l’elenco dei dischi più venduti in Italia nel 2004. Abbastanza imbarazzante a guardarci bene.\nDecisamente non un anno memorabile.\nParticolarmente imbarazzante è il duetto in posizione 19\n
  • Questi erano i libri di riferimento del periodo. Design Patterns era probabilmente quello che andava per la maggiore. E Martin Fowler era l’autorità suprema riconosciuta.\n
  • Java era il linguaggio dominante all’epoca. L’avvallamento del 2004 è stato determinato da un cambio negli algoritmi di ricerca di google più che da un’effettiva variazione.\n
  • In ambiente Java, SUN era ancora l’azienda di riferimento, ed EJB l’architettura di riferimento all’interno del sistema, con tutto l’ambaradan di pattern che era fondamentale conoscere altrimenti non eri nessuno. Una sorta di “nonnismo architetturale” se vogliamo.\n
  • Sebbene mostrasse già evidenti segni di declino, RUP era ancora il processo di sviluppo di riferimento. Mentre il mondo agile si identificava principalmente con XP. Scrum godeva di popolarità minore, almeno in Italia e Kanban doveva ancora essere inventato.\n
  • La progettazione si faceva con bizzarri strumenti che producevano rettangoli gialli gestiti da santoni espertissimi nell’uso della stampante e del nastro adesivo. Bizzarre decorazioni giallastre decoravano gli uffici.\n
  • Lo ammetto. L’ho comprato senza sapere che cosa ci fosse scritto dentro. Unicamente per la frase “Foreword by Martin Fowler”.\n
  • L’ho letto. Lo abbiamo letto. E cosa abbiamo capito? Beh, a tutti è piaciuto il concetto di Ubiquitous Language, ma fondamentalmente abbiamo cercato di fare il paio con le pratiche di design che avevamo già incontrato in Design Patterns e ci siamo fermati lì. Il libro è grosso, ed arrivare in fondo è dura. Molti non ce l’hanno fatta. Molti si sono accontentati di usare Entities e Value Object per poter dire “stiamo facendo DDD”. :-/\n\nMolti non sono mai arrivati alla seconda parte del libro.\n
  • L’ho letto. Lo abbiamo letto. E cosa abbiamo capito? Beh, a tutti è piaciuto il concetto di Ubiquitous Language, ma fondamentalmente abbiamo cercato di fare il paio con le pratiche di design che avevamo già incontrato in Design Patterns e ci siamo fermati lì. Il libro è grosso, ed arrivare in fondo è dura. Molti non ce l’hanno fatta. Molti si sono accontentati di usare Entities e Value Object per poter dire “stiamo facendo DDD”. :-/\n\nMolti non sono mai arrivati alla seconda parte del libro.\n
  • L’ho letto. Lo abbiamo letto. E cosa abbiamo capito? Beh, a tutti è piaciuto il concetto di Ubiquitous Language, ma fondamentalmente abbiamo cercato di fare il paio con le pratiche di design che avevamo già incontrato in Design Patterns e ci siamo fermati lì. Il libro è grosso, ed arrivare in fondo è dura. Molti non ce l’hanno fatta. Molti si sono accontentati di usare Entities e Value Object per poter dire “stiamo facendo DDD”. :-/\n\nMolti non sono mai arrivati alla seconda parte del libro.\n
  • L’ho letto. Lo abbiamo letto. E cosa abbiamo capito? Beh, a tutti è piaciuto il concetto di Ubiquitous Language, ma fondamentalmente abbiamo cercato di fare il paio con le pratiche di design che avevamo già incontrato in Design Patterns e ci siamo fermati lì. Il libro è grosso, ed arrivare in fondo è dura. Molti non ce l’hanno fatta. Molti si sono accontentati di usare Entities e Value Object per poter dire “stiamo facendo DDD”. :-/\n\nMolti non sono mai arrivati alla seconda parte del libro.\n
  • L’ho letto. Lo abbiamo letto. E cosa abbiamo capito? Beh, a tutti è piaciuto il concetto di Ubiquitous Language, ma fondamentalmente abbiamo cercato di fare il paio con le pratiche di design che avevamo già incontrato in Design Patterns e ci siamo fermati lì. Il libro è grosso, ed arrivare in fondo è dura. Molti non ce l’hanno fatta. Molti si sono accontentati di usare Entities e Value Object per poter dire “stiamo facendo DDD”. :-/\n\nMolti non sono mai arrivati alla seconda parte del libro.\n
  • L’ho letto. Lo abbiamo letto. E cosa abbiamo capito? Beh, a tutti è piaciuto il concetto di Ubiquitous Language, ma fondamentalmente abbiamo cercato di fare il paio con le pratiche di design che avevamo già incontrato in Design Patterns e ci siamo fermati lì. Il libro è grosso, ed arrivare in fondo è dura. Molti non ce l’hanno fatta. Molti si sono accontentati di usare Entities e Value Object per poter dire “stiamo facendo DDD”. :-/\n\nMolti non sono mai arrivati alla seconda parte del libro.\n
  • L’ho letto. Lo abbiamo letto. E cosa abbiamo capito? Beh, a tutti è piaciuto il concetto di Ubiquitous Language, ma fondamentalmente abbiamo cercato di fare il paio con le pratiche di design che avevamo già incontrato in Design Patterns e ci siamo fermati lì. Il libro è grosso, ed arrivare in fondo è dura. Molti non ce l’hanno fatta. Molti si sono accontentati di usare Entities e Value Object per poter dire “stiamo facendo DDD”. :-/\n\nMolti non sono mai arrivati alla seconda parte del libro.\n
  • L’ho letto. Lo abbiamo letto. E cosa abbiamo capito? Beh, a tutti è piaciuto il concetto di Ubiquitous Language, ma fondamentalmente abbiamo cercato di fare il paio con le pratiche di design che avevamo già incontrato in Design Patterns e ci siamo fermati lì. Il libro è grosso, ed arrivare in fondo è dura. Molti non ce l’hanno fatta. Molti si sono accontentati di usare Entities e Value Object per poter dire “stiamo facendo DDD”. :-/\n\nMolti non sono mai arrivati alla seconda parte del libro.\n
  • L’ho letto. Lo abbiamo letto. E cosa abbiamo capito? Beh, a tutti è piaciuto il concetto di Ubiquitous Language, ma fondamentalmente abbiamo cercato di fare il paio con le pratiche di design che avevamo già incontrato in Design Patterns e ci siamo fermati lì. Il libro è grosso, ed arrivare in fondo è dura. Molti non ce l’hanno fatta. Molti si sono accontentati di usare Entities e Value Object per poter dire “stiamo facendo DDD”. :-/\n\nMolti non sono mai arrivati alla seconda parte del libro.\n
  • L’ho letto. Lo abbiamo letto. E cosa abbiamo capito? Beh, a tutti è piaciuto il concetto di Ubiquitous Language, ma fondamentalmente abbiamo cercato di fare il paio con le pratiche di design che avevamo già incontrato in Design Patterns e ci siamo fermati lì. Il libro è grosso, ed arrivare in fondo è dura. Molti non ce l’hanno fatta. Molti si sono accontentati di usare Entities e Value Object per poter dire “stiamo facendo DDD”. :-/\n\nMolti non sono mai arrivati alla seconda parte del libro.\n
  • L’ho letto. Lo abbiamo letto. E cosa abbiamo capito? Beh, a tutti è piaciuto il concetto di Ubiquitous Language, ma fondamentalmente abbiamo cercato di fare il paio con le pratiche di design che avevamo già incontrato in Design Patterns e ci siamo fermati lì. Il libro è grosso, ed arrivare in fondo è dura. Molti non ce l’hanno fatta. Molti si sono accontentati di usare Entities e Value Object per poter dire “stiamo facendo DDD”. :-/\n\nMolti non sono mai arrivati alla seconda parte del libro.\n
  • Ok c’è una parte dell’equazione che non abbiamo considerato: il lettore. Io nel 2004 ero un po’ diverso da adesso. Più magro probabilmente. Più ingenuo.\n
  • Ok c’è una parte dell’equazione che non abbiamo considerato: il lettore. Io nel 2004 ero un po’ diverso da adesso. Più magro probabilmente. Più ingenuo.\n
  • Ok c’è una parte dell’equazione che non abbiamo considerato: il lettore. Io nel 2004 ero un po’ diverso da adesso. Più magro probabilmente. Più ingenuo.\n
  • Ok c’è una parte dell’equazione che non abbiamo considerato: il lettore. Io nel 2004 ero un po’ diverso da adesso. Più magro probabilmente. Più ingenuo.\n
  • Ok c’è una parte dell’equazione che non abbiamo considerato: il lettore. Io nel 2004 ero un po’ diverso da adesso. Più magro probabilmente. Più ingenuo.\n
  • Ok c’è una parte dell’equazione che non abbiamo considerato: il lettore. Io nel 2004 ero un po’ diverso da adesso. Più magro probabilmente. Più ingenuo.\n
  • Ok c’è una parte dell’equazione che non abbiamo considerato: il lettore. Io nel 2004 ero un po’ diverso da adesso. Più magro probabilmente. Più ingenuo.\n
  • Ok c’è una parte dell’equazione che non abbiamo considerato: il lettore. Io nel 2004 ero un po’ diverso da adesso. Più magro probabilmente. Più ingenuo.\n
  • Ok c’è una parte dell’equazione che non abbiamo considerato: il lettore. Io nel 2004 ero un po’ diverso da adesso. Più magro probabilmente. Più ingenuo.\n
  • Sulla base di quanto siamo riusciti a capire, siamo partiti garruli e felici alla conquista del nuovo mondo. Convinti che sarebbe stato facile.\n
  • Un primo aspetto da tenere in considerazione è che il libro come strumento divulgativo ha qualche controindicazione. E’ sostanzialmente immutabile: una volta pubblicato ...rimane, mentre la comunità DDD e lo stesso Eric Evans hanno imparato non poco dal feedback conscio o inconscio dei lettori. In particolare, non era stata prevista la distribuzione dell’interesse sui vari argomenti.\n\n
  • Un sacco di domande sul dito.\n
  • Non tutti quelli che hanno provato ad applicare DDD sono stat soddisfatti. Le motivazioni più classiche sono quelle riportate qui sopra. Se aggiungiamo il fatto che nel frattempo siano apparsi Ruby on Rails, Grails ed altri framework RAD, qualche dubbio viene...\n
  • Questa è l’obiezione più frequente. Lo sviluppatore frustrato circondato da colleghi espertissimi nell’arte del copia ed incolla colleghi espertissimi nell’arte del copia ed incolla colleghi espertissimi nell’arte del copia ed incolla colleghi espertissimi nell’arte del copia ed incolla\n
  • Ma suona tanto come un’atteggiamento donchisciottesco. Lancia in resta ed all’attacco dei mulini a vento.\n
  • Probabilmente c’è qualcosa di importante che non abbiamo capito.\n
  • Arriviamo ai giorni nostri. Ne è passata di acqua sotto i ponti.\n
  • Java, oramai territorio Oracle, non è più una piattaforma così interessante. A meno di non includere in “Java” anche linguaggi come Scala, Groovy e JRuby che qualche cosa d’interessante da dire ce l’hanno.\n
  • Java, oramai territorio Oracle, non è più una piattaforma così interessante. A meno di non includere in “Java” anche linguaggi come Scala, Groovy e JRuby che qualche cosa d’interessante da dire ce l’hanno.\n
  • L’esplosione del fenomeno NoSQL, abbastanza imprevedibile nel 2004. In uno scenario in cui i database ad oggetti erano considerati degli oggetti costosissimi e non sufficientemente affidabili/performanti.\n
  • Ma il buon Eric lo disse in tempi non sospetti per commentare la complessità accidentale introdotta dagli ORM.\n
  • Per non parlare della rivoluzione introdotta da Greg Young ed Udi Dahan quando hanno iniziato a portare avanti Command Query Responsibility Segregation. Performance ed un nuovo paradigma di modellazione.\n
  • Un’architettura per i comandi ed un’architettura per accedere ai dati. Ciascuna ottimizzata senza compromessi. Una figata.\n
  • Il concetto di evento di dominio, qualcosa che è avvenuto nel sistema, modellato come un verbo al participio passato, diventa un elemento centrale sia della tradizionale architettura DDD sia di quelle più avveniristiche come CQRS ed Event Sourcing.\n
  • Il legame tra TDD e DDD era già forte nelle fasi iniziali\n
  • Ma dalla comunità DDD (in particolare grazie al contributo di Dan North e successivamente di Aslak Hellesoy) nascono strumenti che rivoluzionano l’approccio al testing portando al centro del test la necessità di rendere il test accessibile anche ai ruoli non di sviluppo, attraverso un lavoro sul linguaggio che porta ai test in linguaggio naturale di Cucumber, e delle sue declinazioni in altri linguaggi, come SpecFlow.\n
  • Per colmare un piccolo vuoto informativo, Eric Evans presenta qualcosa che assomiglia un po’ di più ad un processo di riferimento. La chiave di volta è l’uso di differenti strumenti per raffinare continuamente il modello, in modalità “pull”. \n
  • Ma soprattutto, nel 2011 il duetto di Tiziano ferro e Jamelia è solo uno sbiadito ricordo.\n
  • Purtroppo però sul fronte editoriale non si è mosso molto. E le novità hanno un po’ complicato il quadro. Ciò nonostante, i progetti andavano in porto e la comunità DDD era attiva e sempre più convinta.\n
  • Tempo di fare il punto della situazione. Di raccogliere alcuni tra i personaggi più attivi ed influenti della comunità, per sincronizzarsi e scambiarsi idee in una “collaborazione creativa” :-)\n
  • Ed eccoci qua, in quel di Portland ME a discutere per 3 intensi giorni, di un po’ di tutto. Tra una camminata per i boschi, una partita di baseball, un’interminabile discussione sui Bounded Contexts, ed un po’ di birra.\n
  • ... per arrivare ad una nuova versione della definizione di cosa sia DDD.\n
  • Ok, ma cosa intendiamo esattamente per Core Domain? Era nella seconda parte del libro, quindi ...forse ce lo siamo persi.\n
  • Questa è il diagramma su cui siamo riusciti ad avere un minimo di consenso. Troviamo tutte e quattro le categorie di partizionamento di DDD, in colori diversi.\n
  • Ma dopo interminabili discussioni, sulla via del ritorno mi sono finalmente reso conto che il core domain aveva una forma molto riconoscibile.\n
  • Se il nostro dominio è un maiale, la coscia è il nostro Core Domain.\n
  • L’area in cui concentrarci per raggiungere l’eccellenza. Perché la qualità in questa zona paga.\n
  • Ha senso dedicare le stesse energie alla pancetta? In qualche caso può avere senso.\n
  • In altri casi la pancetta non fa alcuna differenza, ed allora possiamo esternalizzare il processo o adottare strategie Low Cost.\n
  • Ma è sempre pancetta. Come posso capire quali strategia applicare e quando?\n
  • E’ che non si tratta di un problema di architettura software. E’ un problema business.\n\n
  • Che cosa sia core domain è determinato essenzialmente dal contesto di mercato in cui ci troviamo. E potrà cambiare. E cambierà, in maniera indipendente dalla nostra volontà.\n\nI Bounded Contexts invece sono il risultato del contesto di sviluppo in cui ci troviamo, della dimensione e della dislocazione del team di sviluppo. E delle soluzioni tecniche che adottiamo.\n
  • Durante il DDD Summit, abbiamo cercato di categorizzare alcuni aspetti chiave di DDD.\nIn azzurro ciò che era core, in verde gli aspetti supporting, in giallo quelli generic o comunque non così strettamente correlati a DDD, mentre in rosso ciò che non era DDD.\n
  • E questo è il distillato delle aree che hanno raggiunto il maggiore consenso.\n
  • Interessante. Dove sono gli aspetti legati al codice?\n
  • E se forse la cosa che non abbiamo capito, o il peccato originale fosse stato pensare che con un paio di factory e di value object avessimo potuto cambiare il mondo? O semplicemente se il pubblico fosse stato sbagliato?\n
  • Nel frattempo, Dan North - si sempre lui, quello di JBehave che poi è diventato Cucumber - se ne è uscito con un post spettacolare sul concetto di Deliberate Learning. Andatelo a leggere.\n
  • E’ l’ignoranza che ci frega. E nel momento di massima ignoranza spesso prendiamo le decisioni più vincolanti.\n
  • E se lavorassimo sull’ignoranza? \n
  • E se riuscissimo ad anticipare in qualche modo il momento in cui finalmente capiamo cosa abbiamo sbagliato?\n
  • Su questo punto al DDD summit siamo stati praticamente unanimi.\n
  • Non è una contrapposizione. In DDD è un’allineamento. Non possiamo produrre software senza imparare, ma non possiamo nemmeno imparare senza produrre software. Testando la nostra capacità di comprendere il dominio.\n
  • Ma se il limite è l’apprendimento allora dobbiamo essere consapevoli di essere ignoranti in materia.\n
  • Il vero saggio è colui che sa di non sapere...\n
  • Ma dobbiamo anche renderci conto che abbiamo a disposizione strumenti che non sono disponibili alle altre discipline\n
  • Come il TDD.\n
  • \n
  • O possiamo sperimentarne di altri. Non deve essere faticoso imparare. Anzi.\n
  • L’ecosistema è importante.\n
  • \n
  • Apparentemente il nostro contributo pare limitarsi alla formalizzazione di un modello per un dominio complesso. Il punto è che in dominii non ancora ben consolidati c’è un sacco di spazio per l’esplorazione e per capire bene cosa sia il modello.\n\nNella realtà dei fatti, questo accade anche per dominii consolidati. Dove tutti fanno la stessa cosa e dove un approccio sperimentale può ribaltare il tavolo e definire un nuovo paradigma. Succede. Succede solo provando. Può succedere a noi.\n
  • Un alto elemento chiave dell’approccio è quello dell’introduzione dei buonded context ad ogni livello della discussione. Non esiste un modello unico. Esiste un contesto in cui questo modello è il migliore che conosciamo. Per risolvere un altro problema in un altro contesto, esiste un altro modello.\n
  • E ...SORPRESA! DDD non è uno stile architetturale o un’architettura. Se nel 2004 il Domain Model Pattern era l’unica alternativa visibile nel panorama dell’epoca, non significa che sia un vincolo irrinunciabile.\n\nIn generale tutto l’aspetto dell’architettura diventa in DDD supporting. E diverse sono le alternative possibili. Il tutto nel rispetto dei principi e dei valori di DDD.\n
  • E’ interessante notare che in tutti questi approcci, gli aggregati restano centrali.\n\nHo incluso anche DCI... sì. Date un’occhiata a Qi4J e ne riparliamo.\n
  • Ecco un aspetto che è mutato sottotraccia rispetto al 2004. Nella stesura originale, DDD e una Rich UI sono presentati come concetti antitetici. Ma nel 2011 rinunciare a una Rich UI è probabilmente una scelta strategicamente suicida. Non dimentichiamoci che sono stati fatti passi da gigante in quel settore.\n
  • In generale, quello che è interessante è vedere come esistano differenti approcci alla gestione nella complessità con i quali possiamo trovare dei punti in comune.\n
  • Se siamo stati bravi - ma solo se siamo stati bravi - la maggior parte della complessità è nascosta all’utente, che nel suo percorso di interazione con il nostro sistema ne vede solo una porzione.\nDal punto di vista della UX (grazie a Gianluca Brugnoli che mi ha illuminato sull’argomento) questi sono Touch Points. Dal punto di vista dell’applicazione sono Use Case. Sono la stessa cosa. ...non tutti i Touch Points sono Use Case però… alcune interazioni sono con il cassiere allo sportello, con il treno, etc.\n
  • Se siamo stati bravi - ma solo se siamo stati bravi - la maggior parte della complessità è nascosta all’utente, che nel suo percorso di interazione con il nostro sistema ne vede solo una porzione.\nDal punto di vista della UX (grazie a Gianluca Brugnoli che mi ha illuminato sull’argomento) questi sono Touch Points. Dal punto di vista dell’applicazione sono Use Case. Sono la stessa cosa. ...non tutti i Touch Points sono Use Case però… alcune interazioni sono con il cassiere allo sportello, con il treno, etc.\n
  • Se siamo stati bravi - ma solo se siamo stati bravi - la maggior parte della complessità è nascosta all’utente, che nel suo percorso di interazione con il nostro sistema ne vede solo una porzione.\nDal punto di vista della UX (grazie a Gianluca Brugnoli che mi ha illuminato sull’argomento) questi sono Touch Points. Dal punto di vista dell’applicazione sono Use Case. Sono la stessa cosa. ...non tutti i Touch Points sono Use Case però… alcune interazioni sono con il cassiere allo sportello, con il treno, etc.\n
  • Se siamo stati bravi - ma solo se siamo stati bravi - la maggior parte della complessità è nascosta all’utente, che nel suo percorso di interazione con il nostro sistema ne vede solo una porzione.\nDal punto di vista della UX (grazie a Gianluca Brugnoli che mi ha illuminato sull’argomento) questi sono Touch Points. Dal punto di vista dell’applicazione sono Use Case. Sono la stessa cosa. ...non tutti i Touch Points sono Use Case però… alcune interazioni sono con il cassiere allo sportello, con il treno, etc.\n
  • Se siamo stati bravi - ma solo se siamo stati bravi - la maggior parte della complessità è nascosta all’utente, che nel suo percorso di interazione con il nostro sistema ne vede solo una porzione.\nDal punto di vista della UX (grazie a Gianluca Brugnoli che mi ha illuminato sull’argomento) questi sono Touch Points. Dal punto di vista dell’applicazione sono Use Case. Sono la stessa cosa. ...non tutti i Touch Points sono Use Case però… alcune interazioni sono con il cassiere allo sportello, con il treno, etc.\n
  • Se siamo stati bravi - ma solo se siamo stati bravi - la maggior parte della complessità è nascosta all’utente, che nel suo percorso di interazione con il nostro sistema ne vede solo una porzione.\nDal punto di vista della UX (grazie a Gianluca Brugnoli che mi ha illuminato sull’argomento) questi sono Touch Points. Dal punto di vista dell’applicazione sono Use Case. Sono la stessa cosa. ...non tutti i Touch Points sono Use Case però… alcune interazioni sono con il cassiere allo sportello, con il treno, etc.\n
  • Il punto è che ...se c’è qualcuno oltre a noi che è interessato a questioni come l’integrità concettuale o alla consistenza del linguaggio attraverso un’interazione con la nostra applicazione, questo è una persona con cui di solito non parliamo molto: l’architetto dell’informazione.\n\nOffritegli un caffè. Ne vale la pena.\n
  • Troppa energia e troppa fatica. Non aspettatevi una nuova edizione del blue book.\n\nMa dovrebbe essere evidente che è stato progettato per avere un’obsolescenza molto meno rapida di tanti altri. Il focus è sui principi, e restano sostanzialmente validi.\n
  • E quindi ci limitiamo ad essere una società segreta che discute sulle interpretazioni di un unico libro?\n
  • Non proprio. Uno dei punti forti del Summit è stata anche la decisione di uno sforzo collettivo per pubblicare materiale\n
  • Date un’occhiata al sito ufficiale DDD, stay tuned.\n
  • \n
  • \n
  • E’ forse stata una delle parti più difficili del summit. Convergere sul perché.\nIl fatto è che ci piace, è utile, ci fa sentire bene. Ma fondamentalmente restiamo dei professionisti dello sviluppo software che stanno cercando il modo migliore per scrivere software utile per risolvere i problemi di qualcuno, da qualche parte del mondo.\n
  • Ok, if that’s the answer... If you really like that and think that’s the best possible world... then I don’t have so much to tell you.\n

DDD 2011 - Dove Desideriamo Dirigerci DDD 2011 - Dove Desideriamo Dirigerci Presentation Transcript

  • Dove
Desideriamo
 Dirigerci?
  • About
meIn
the
IT
field
since
ZX
SpectrumGenerally
in
large
scale
projects
(I
might
be
biased)Freelance
consultant:
NotOnlyCodeTrainer
(Freelance
&
Skills
MaBer
+
Zenika)Technical
WriterBlogger:
h<p://ziobrando.blogspot.comTwiBer:
ziobrando
My
e‐mail:
alberto.brandolini@gmail.com
  • @avanscopertawww.avanscoperta.itavanscoperta.wordpress.comalberto.brandolini@avanscoperta.it ©
Alberto
Brandolini
2009
  • The world in 2004 ©
Alberto
Brandolini
2011
  • Ascoltavamo...1. F**k it (I dont want you back) - Eamon [# 1, 2004/05]2. A chi mi dice (Breath easy) - Blue [# 1, 2004/05]3. Dragostea din tei - Haiducii vs Gabry Ponte [# 1]4. Left outside alone - Anastacia [# 1, 2004/05]5. Hey ya! - Outkast [# 2, 2003/04]6. Yeah - Usher feat. Lil Jon & Ludacris [# 3, 2004/05]7. In the shadows - The Rasmus [# 2, 2003/04]8. Curtain falls - Blue [# 1, 2004/05]9. Sick and tired - Anastacia [# 2, 2004/05]10.Superstar - Jamelia [# 3]11.Lose my breath - Destinys Child [# 1, 2004/05]12.Resta in ascolto - Laura Pausini [# 1]13.Shut up - The Black Eyed Peas [# 2]14.Vertigo - U2 [# 1, 2004/05]15.Calma e sangue freddo - Luca Dirisio [# 2, 2004/05]16.Turn me on - Kevin Lyttle [# 3]17.This love - Maroon 5 [# 4, 2004/05]18.Spiderman - Michael Bublè [# 3, 2004/05]19.Universal prayer - Tiziano Ferro feat. Jamelia [# 1, 2004/05]20.Toxic - Britney Spears [# 5] ©
Alberto
Brandolini
2011
  • Ascoltavamo...1. F**k it (I dont want you back) - Eamon [# 1, 2004/05]2. A chi mi dice (Breath easy) - Blue [# 1, 2004/05]3. Dragostea din tei - Haiducii vs Gabry Ponte [# 1]4. Left outside alone - Anastacia [# 1, 2004/05]5. Hey ya! - Outkast [# 2, 2003/04]6. Yeah - Usher feat. Lil Jon & Ludacris [# 3, 2004/05]7. In the shadows - The Rasmus [# 2, 2003/04]8. Curtain falls - Blue [# 1, 2004/05]9. Sick and tired - Anastacia [# 2, 2004/05]10.Superstar - Jamelia [# 3]11.Lose my breath - Destinys Child [# 1, 2004/05]12.Resta in ascolto - Laura Pausini [# 1]13.Shut up - The Black Eyed Peas [# 2] nt o. .14.Vertigo - U2 [# 1, 2004/05] ci co15.Calma e sangue freddo - Luca Dirisio [# 2, 2004/05] o16.Turn me on - Kevin Lyttle [# 3] nd i am Re17.This love - Maroon 5 [# 4, 2004/05]18.Spiderman - Michael Bublè [# 3, 2004/05]19.Universal prayer - Tiziano Ferro feat. Jamelia [# 1, 2004/05]20.Toxic - Britney Spears [# 5] ©
Alberto
Brandolini
2011
  • leggevamo ©
Alberto
Brandolini
2011
  • Java andava per la maggiore ©
Alberto
Brandolini
2011
  • E nel mondo Java... ©
Alberto
Brandolini
2011
  • ...parlando di processo... - RUP come paradigma dominante XP come metodologiaagile emergente ©
Alberto
Brandolini
2011
  • Si progetta in UML ©
Alberto
Brandolini
2011
  • Poi arrivò il libro... ©
Alberto
Brandolini
2011
  • Ed imparammo qualcosa ©
Alberto
Brandolini
2011
  • Ed imparammo qualcosa- Ubiquitous language ©
Alberto
Brandolini
2011
  • Ed imparammo qualcosa- Ubiquitous language- Domain Model Pattern ©
Alberto
Brandolini
2011
  • Ed imparammo qualcosa- Ubiquitous language- Domain Model Pattern- Entities ©
Alberto
Brandolini
2011
  • Ed imparammo qualcosa- Ubiquitous language- Domain Model Pattern- Entities- Value Objects ©
Alberto
Brandolini
2011
  • Ed imparammo qualcosa- Ubiquitous language- Domain Model Pattern- Entities- Value Objects- Factories ©
Alberto
Brandolini
2011
  • Ed imparammo qualcosa- Ubiquitous language- Domain Model Pattern- Entities- Value Objects- Factories- Aggregates ©
Alberto
Brandolini
2011
  • Ed imparammo qualcosa- Ubiquitous language- Domain Model Pattern- Entities- Value Objects- Factories- Aggregates- Repositories ©
Alberto
Brandolini
2011
  • Ed imparammo qualcosa- Ubiquitous language- Domain Model Pattern- Entities- Value Objects- Factories- Aggregates- Repositories- Services ©
Alberto
Brandolini
2011
  • Ed imparammo qualcosa- Ubiquitous language- Domain Model Pattern - Entities - Value Objects - Factories - Aggregates - Repositories - Services- ... Bounded Contexts ©
Alberto
Brandolini
2011
  • Ed imparammo qualcosa- Ubiquitous language- Domain Model Pattern - Entities - Value Objects - Factories - Aggregates - Repositories - Services- ... Bounded Contexts- ... Context Mapping? ©
Alberto
Brandolini
2011
  • Ed imparammo qualcosa- Ubiquitous language- Domain Model Pattern - Entities - Value Objects - Factories - Aggregates - Repositories - Services- ... Bounded Contexts- ... Context Mapping?- ... Core domain? ©
Alberto
Brandolini
2011
  • Io nel 2004 ©
Alberto
Brandolini
2011
  • Io nel 2004- Consulente in giacca e cravatta ©
Alberto
Brandolini
2011
  • Io nel 2004- Consulente in giacca e cravatta- Analisi ©
Alberto
Brandolini
2011
  • Io nel 2004- Consulente in giacca e cravatta- Analisi- Design ©
Alberto
Brandolini
2011
  • Io nel 2004- Consulente in giacca e cravatta- Analisi- Design- Sviluppo ©
Alberto
Brandolini
2011
  • Io nel 2004- Consulente in giacca e cravatta- Analisi- Design- Sviluppo- Test ©
Alberto
Brandolini
2011
  • Io nel 2004- Consulente in giacca e cravatta- Analisi- Design- Sviluppo- Test- System Integration ©
Alberto
Brandolini
2011
  • Io nel 2004- Consulente in giacca e cravatta- Analisi- Design- Sviluppo- Test- System Integration- Java ...J2EE ©
Alberto
Brandolini
2011
  • Io nel 2004- Consulente in giacca e cravatta- Analisi- Design- Sviluppo- Test- System Integration- Java ...J2EE- Arial (o al massimo verdana) ©
Alberto
Brandolini
2011
  • Io nel 2004- Consulente in giacca e cravatta- Analisi- Design- Sviluppo- Test- System Integration- Java ...J2EE- Arial (o al massimo verdana)- elenchi puntati ©
Alberto
Brandolini
2011
  • Lessons
(learned?)
  • “90% of the questions onthe DDD mailing list used to be about Aggregates and Repositories” Eric Evans
  • Qualche fallimento DDD è troppo costoso DDD è troppo complesso DDD è troppo esigente DDD richiede troppo tempo avanscoper ta
  • Sono l’unico a capirciqualcosa di DDD avanscoper ta
  • All’a<acco!
  • Cosa
ci
siamo
persi?
  • The
world
in
2011
  • Java
nel
2011
  • Java
nel
2011
  • Java
nel
2011...solo
i
vecchi
lo
guardano....
  • No
SQL ©
Alberto
Brandolini
2011
  • “We spend too much time on simplypersisting the domain” Eric Evans
  • ! The

 Command Query? revoluQon
  • !? UI DTO CommandsRemote
facade Remote
facade ApplicaQon
Services Thin
Read
Layer ORM
? Events publish
subscribe
  • Domain
EventÈ
successo
qualcosa
che
ci
interessa
  • s TDD
and
DDD Frequent
rewriQng Focus
on
Unit
Tests Exploratory
coding Frequent
Short
Cycles Tiny
Domain
Objects Quick
Feedback Self
explanatory
code Freedom
to
change ©
Alberto
Brandolini
‐
2010
  • BDD
&
DDDBe<er
communicaQon
 with
Domain
Experts Overlapping
CommuniQes enforcing
a
consistent
 Ubiquitous
Language ©
Alberto
Brandolini
2011
  • ©
Alberto
Brandolini
2011
  • ©
Alberto
Brandolini
2011
  • ti ! ica e ntD im ©
Alberto
Brandolini
2011
  • Cos’è
Domain‐Driven
 Design
 nel
2011?
  • Maggio
2011
‐
Portland
  • DDD
è
un
insieme
di
principiFocus
on
the
core
domainExplore
models
in
a
creaQve
collaboraQon
of
domain
pracQQoners
and
soWware
pracQQonersSpeak
a
ubiquitous
language
within
an
explicitly
bounded
context

  • Core
domain?
  • C o re D om a i n
  • Core
DomainNon
fare
nulla
di
meno
del
vostro
meglio
  • SupporQng
subdomain
  • Or...
  • ...un
momento!
  • Auditing Delivery Delivery ManagementOld Legacy component Invoicing System AC L InvoicingBooking New Booking System ©
Alberto
Brandolini
2011
  • Core
DomainGuidato
dal
businessSpazio
dei
problemi Bounded
Contexts “guidato”
dallo
sviluppo spazio
delle
soluzioni ©
Alberto
Brandolini
2011
  • Bounded
ContextsUbiquitous
LanguageBe<er
Understanding
of
the
domainCreaQve
CollaboraQonAggregates
  • Bounded
ContextsUbiquitous
LanguageBe<er
Understanding
of
the
domainCreaQve
CollaboraQonAggregates
  • E
se
DDD
non
fosse
una
cosa
 solo
per
sviluppatori?
  • Ignorance
is
the
single
 greatest
impediment
 to
throughput Dan
North
  • 100% 90% 80% 70%Ignorance 60% 50% 40% Ignorance 30% 20% 10% 0 0 1 2 3 4 5 6 7 8 9 10 Time
  • 100% Th i s i s 90% whe n c r i t ic a we m a l de c i s ke 80% io ns 70%Ignorance 60% 50% 40% Ignorance 30% 20% 10% 0 0 1 2 3 4 5 6 7 8 9 10 Time
  • 100% 90% 80% B re a kt 70% h ro u g hIgnorance 60% 50% 40% Ignorance 30% 20% 10% 0 0 1 2 3 4 5 6 7 8 9 10 Time
  • 100% 90% 80% B re a kt 70% Can w h ro u g h e a n t icIgnorance 60% t his m i p a te ome n t 50% ? 40% Ignorance 30% 20% 10% 0 0 1 2 3 4 5 6 7 8 9 10 Time
  • 100% 90% 80% B re a kt 70% h ro u g hIgnorance 60% 50% 40% Ignorance 30% 20% 10% 0 0 1 2 3 4 5 6 7 8 9 10 Time
  • l’apprendimento
è
un
 dominio
di
cui
sappiamo
ancora
poco
  • ...se
avessi
avuto
i
test...
  • Abbiamo
a
disposizione
strumenQ
incredibili
per
 imparare
  • s TDD
and
DDD Frequent
rewriQng Focus
on
Unit
Tests Exploratory
coding Frequent
Short
Cycles Tiny
Domain
Objects Quick
Feedback Self
explanatory
code Freedom
to
change ©
Alberto
Brandolini
‐
2010
  • Ah,
se
avessi
avuto
i
test......se
avessi
avuto
i
test...
  • Explore
&
Play
  • L’ecosistema E’
necessario
un
processo
di
 sviluppo
agile,
che
permeBa
di
 raccogliere
il
feedback
di
utenQ
e
domain
experts,
in
iterazioni
brevi. ©
Alberto
Brandolini
2009
  • E’
necessario
un
processo
di
 sviluppo
agile,
che
permeBa
di
 raccogliere
il
feedback
di
utenQ
e
 Il
nostro
obie]vo
è
stabilire
una
domain
experts,
in
iterazioni
brevi. collaborazione
creaQva
 ©
Alberto
Brandolini
2009
  • gli
esperQ
ci
 e
noi
aiuQamo
aiutano
a
capire loro ©
Alberto
Brandolini
2009
  • Bounded
Context
  • DDD
non
è
uno
 s7le
archite8urale ©
Alberto
Brandolini
2011
  • DDD
SupporQng
Architectures Domain
Model
Pa<ern Hexagonal
Architecture Event
Sourcing CQRS ...DCI?
  • Rich
UI
and
DDD
  • Complexity Application Complexity Domain Complexity
  • ...seen
by
the
user Application Complexity Domain Complexity User
  • ...seen
by
the
user Application Complexity Domain Complexity User
  • ...seen
by
the
user Application Complexity Domain Complexity User
  • ...seen
by
the
user Application Complexity Domain Complexity User
  • ...seen
by
the
user Application Complexity Domain Complexity User
  • ...seen
by
the
user Application Complexity Domain Complexity User
  • ...seen
by
the
user Application Complexity Domain Complexity User
  • InformaQon
 DDD
 ArchitectpracQcionerSQamo
guardando
alla
stessa
cosa...
  • “There will be no second edition of the book” Eric Evans
  • Non
esa<amente...
:‐)
  • Dove
Desideriamo
 Dirigerci?
  • Perché
facciamo
tu<o
 questo?
  • WriQng
Socware
 That
Ma<ers
  • Thank
youalberto.brandolini@avanscoperta.it hBp://ziobrando.blogspot.com twiBer:
ziobrando