DDD 2011 - Dove Desideriamo Dirigerci
•Download as KEY, PDF•
5 likes•1,235 views
La mia presentazione sull'evoluzione di DDD dall'uscita del libro nel 2004 ad oggi. Presentata al DDD-Day, in italiano.
Recommended
Recommended
More Related Content
Similar to DDD 2011 - Dove Desideriamo Dirigerci
Similar to DDD 2011 - Dove Desideriamo Dirigerci (7)
More from Alberto Brandolini
More from Alberto Brandolini (20)
DDD 2011 - Dove Desideriamo Dirigerci
- 1. Dove Desideriamo Dirigerci?
- 3. @avanscoperta www.avanscoperta.it avanscoperta.wordpress.com alberto.brandolini@avanscoperta.it © Alberto Brandolini 2009
- 4. The world in 2004 © Alberto Brandolini 2011
- 5. Ascoltavamo... 1. F**k it (I don't 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 - Destiny's 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
- 6. Ascoltavamo... 1. F**k it (I don't 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 - Destiny's 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 co 15.Calma e sangue freddo - Luca Dirisio [# 2, 2004/05] o 16.Turn me on - Kevin Lyttle [# 3] nd i am Re 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
- 7. leggevamo © Alberto Brandolini 2011
- 8. Java andava per la maggiore © Alberto Brandolini 2011
- 9. E nel mondo Java... © Alberto Brandolini 2011
- 10. ...parlando di processo... - RUP come paradigma dominante XP come metodologia agile emergente © Alberto Brandolini 2011
- 11. Si progetta in UML © Alberto Brandolini 2011
- 12. Poi arrivò il libro... © Alberto Brandolini 2011
- 13. Ed imparammo qualcosa © Alberto Brandolini 2011
- 14. Ed imparammo qualcosa - Ubiquitous language © Alberto Brandolini 2011
- 15. Ed imparammo qualcosa - Ubiquitous language - Domain Model Pattern © Alberto Brandolini 2011
- 16. Ed imparammo qualcosa - Ubiquitous language - Domain Model Pattern - Entities © Alberto Brandolini 2011
- 17. Ed imparammo qualcosa - Ubiquitous language - Domain Model Pattern - Entities - Value Objects © Alberto Brandolini 2011
- 18. Ed imparammo qualcosa - Ubiquitous language - Domain Model Pattern - Entities - Value Objects - Factories © Alberto Brandolini 2011
- 19. Ed imparammo qualcosa - Ubiquitous language - Domain Model Pattern - Entities - Value Objects - Factories - Aggregates © Alberto Brandolini 2011
- 20. Ed imparammo qualcosa - Ubiquitous language - Domain Model Pattern - Entities - Value Objects - Factories - Aggregates - Repositories © Alberto Brandolini 2011
- 21. Ed imparammo qualcosa - Ubiquitous language - Domain Model Pattern - Entities - Value Objects - Factories - Aggregates - Repositories - Services © Alberto Brandolini 2011
- 22. Ed imparammo qualcosa - Ubiquitous language - Domain Model Pattern - Entities - Value Objects - Factories - Aggregates - Repositories - Services - ... Bounded Contexts © Alberto Brandolini 2011
- 23. Ed imparammo qualcosa - Ubiquitous language - Domain Model Pattern - Entities - Value Objects - Factories - Aggregates - Repositories - Services - ... Bounded Contexts - ... Context Mapping? © Alberto Brandolini 2011
- 24. Ed imparammo qualcosa - Ubiquitous language - Domain Model Pattern - Entities - Value Objects - Factories - Aggregates - Repositories - Services - ... Bounded Contexts - ... Context Mapping? - ... Core domain? © Alberto Brandolini 2011
- 25. Io nel 2004 © Alberto Brandolini 2011
- 26. Io nel 2004 - Consulente in giacca e cravatta © Alberto Brandolini 2011
- 27. Io nel 2004 - Consulente in giacca e cravatta - Analisi © Alberto Brandolini 2011
- 28. Io nel 2004 - Consulente in giacca e cravatta - Analisi - Design © Alberto Brandolini 2011
- 29. Io nel 2004 - Consulente in giacca e cravatta - Analisi - Design - Sviluppo © Alberto Brandolini 2011
- 30. Io nel 2004 - Consulente in giacca e cravatta - Analisi - Design - Sviluppo - Test © Alberto Brandolini 2011
- 31. Io nel 2004 - Consulente in giacca e cravatta - Analisi - Design - Sviluppo - Test - System Integration © Alberto Brandolini 2011
- 32. Io nel 2004 - Consulente in giacca e cravatta - Analisi - Design - Sviluppo - Test - System Integration - Java ...J2EE © Alberto Brandolini 2011
- 33. Io nel 2004 - Consulente in giacca e cravatta - Analisi - Design - Sviluppo - Test - System Integration - Java ...J2EE - Arial (o al massimo verdana) © Alberto Brandolini 2011
- 34. 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
- 36. “90% of the questions on the DDD mailing list used to be about Aggregates and Repositories” Eric Evans
- 38. Qualche fallimento DDD è troppo costoso DDD è troppo complesso DDD è troppo esigente DDD richiede troppo tempo avanscoper ta
- 39. Sono l’unico a capirci qualcosa di DDD avanscoper ta
- 40. All’a<acco!
- 43. Java nel 2011
- 44. Java nel 2011
- 46. No SQL © Alberto Brandolini 2011
- 47. “We spend too much time on simply persisting the domain” Eric Evans
- 48. ! The Command Query ? revoluQon
- 49. ! ? UI DTO Commands Remote facade Remote facade ApplicaQon Services Thin Read Layer ORM ? Events publish subscribe
- 51. 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
- 52. BDD & DDD Be<er communicaQon with Domain Experts Overlapping CommuniQes enforcing a consistent Ubiquitous Language © Alberto Brandolini 2011
- 55. ti ! ica e nt D im © Alberto Brandolini 2011
- 56. Cos’è Domain‐Driven Design nel 2011?
- 60. Core domain?
- 64. C o re D om a i n
- 67. Or...
- 68. ...un momento!
- 69. Auditing Delivery Delivery Management Old Legacy component Invoicing System AC L Invoicing Booking New Booking System © Alberto Brandolini 2011
- 70. Core Domain Guidato dal business Spazio dei problemi Bounded Contexts “guidato” dallo sviluppo spazio delle soluzioni © Alberto Brandolini 2011
- 74. E se DDD non fosse una cosa solo per sviluppatori?
- 75. Ignorance is the single greatest impediment to throughput Dan North
- 76. 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
- 77. 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
- 78. 100% 90% 80% B re a kt 70% h ro u g h Ignorance 60% 50% 40% Ignorance 30% 20% 10% 0 0 1 2 3 4 5 6 7 8 9 10 Time
- 79. 100% 90% 80% B re a kt 70% Can w h ro u g h e a n t ic Ignorance 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
- 80. 100% 90% 80% B re a kt 70% h ro u g h Ignorance 60% 50% 40% Ignorance 30% 20% 10% 0 0 1 2 3 4 5 6 7 8 9 10 Time
- 83. l’apprendimento è un dominio di cui sappiamo ancora poco
- 85. Abbiamo a disposizione strumenQ incredibili per imparare
- 86. 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
- 88. Explore & Play
- 89. 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
- 90. 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
- 91. gli esperQ ci e noi aiuQamo aiutano a capire loro © Alberto Brandolini 2009
- 92. Bounded Context
- 93. DDD non è uno s7le archite8urale © Alberto Brandolini 2011
- 94. DDD SupporQng Architectures Domain Model Pa<ern Hexagonal Architecture Event Sourcing CQRS ...DCI?
- 95. Rich UI and DDD
- 96. Complexity Application Complexity Domain Complexity
- 97. ...seen by the user Application Complexity Domain Complexity User
- 98. ...seen by the user Application Complexity Domain Complexity User
- 99. ...seen by the user Application Complexity Domain Complexity User
- 100. ...seen by the user Application Complexity Domain Complexity User
- 101. ...seen by the user Application Complexity Domain Complexity User
- 102. ...seen by the user Application Complexity Domain Complexity User
- 103. ...seen by the user Application Complexity Domain Complexity User
- 104. InformaQon DDD Architect pracQcioner SQamo guardando alla stessa cosa...
- 105. “There will be no second edition of the book” Eric Evans
- 109. Dove Desideriamo Dirigerci?
- 110. Perché facciamo tu<o questo?
- 112. Thank you alberto.brandolini@avanscoperta.it hBp://ziobrando.blogspot.com twiBer: ziobrando
Editor's Notes
- \n
- \n
- And that&#x2019;s the company I started one year ago.\n
- Cominciamo guardando indietro. A dove eravamo. Il libro DDD &#xE8; uscito nel 2004 e la sua gestazione &#xE8; durata quattro anni. Molte delle considerazioni presenti nel libro sono espresse tenendo conto del contesto dell&#x2019;epoca.\n
- Questo &#xE8; l&#x2019;elenco dei dischi pi&#xF9; venduti in Italia nel 2004. Abbastanza imbarazzante a guardarci bene.\nDecisamente non un anno memorabile.\nParticolarmente imbarazzante &#xE8; 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&#x2019;autorit&#xE0; suprema riconosciuta.\n
- Java era il linguaggio dominante all&#x2019;epoca. L&#x2019;avvallamento del 2004 &#xE8; stato determinato da un cambio negli algoritmi di ricerca di google pi&#xF9; che da un&#x2019;effettiva variazione.\n
- In ambiente Java, SUN era ancora l&#x2019;azienda di riferimento, ed EJB l&#x2019;architettura di riferimento all&#x2019;interno del sistema, con tutto l&#x2019;ambaradan di pattern che era fondamentale conoscere altrimenti non eri nessuno. Una sorta di &#x201C;nonnismo architetturale&#x201D; se vogliamo.\n
- Sebbene mostrasse gi&#xE0; 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&#xE0; 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&#x2019;uso della stampante e del nastro adesivo. Bizzarre decorazioni giallastre decoravano gli uffici.\n
- Lo ammetto. L&#x2019;ho comprato senza sapere che cosa ci fosse scritto dentro. Unicamente per la frase &#x201C;Foreword by Martin Fowler&#x201D;.\n
- L&#x2019;ho letto. Lo abbiamo letto. E cosa abbiamo capito? Beh, a tutti &#xE8; piaciuto il concetto di Ubiquitous Language, ma fondamentalmente abbiamo cercato di fare il paio con le pratiche di design che avevamo gi&#xE0; incontrato in Design Patterns e ci siamo fermati l&#xEC;. Il libro &#xE8; grosso, ed arrivare in fondo &#xE8; dura. Molti non ce l&#x2019;hanno fatta. Molti si sono accontentati di usare Entities e Value Object per poter dire &#x201C;stiamo facendo DDD&#x201D;. :-/\n\nMolti non sono mai arrivati alla seconda parte del libro.\n
- L&#x2019;ho letto. Lo abbiamo letto. E cosa abbiamo capito? Beh, a tutti &#xE8; piaciuto il concetto di Ubiquitous Language, ma fondamentalmente abbiamo cercato di fare il paio con le pratiche di design che avevamo gi&#xE0; incontrato in Design Patterns e ci siamo fermati l&#xEC;. Il libro &#xE8; grosso, ed arrivare in fondo &#xE8; dura. Molti non ce l&#x2019;hanno fatta. Molti si sono accontentati di usare Entities e Value Object per poter dire &#x201C;stiamo facendo DDD&#x201D;. :-/\n\nMolti non sono mai arrivati alla seconda parte del libro.\n
- L&#x2019;ho letto. Lo abbiamo letto. E cosa abbiamo capito? Beh, a tutti &#xE8; piaciuto il concetto di Ubiquitous Language, ma fondamentalmente abbiamo cercato di fare il paio con le pratiche di design che avevamo gi&#xE0; incontrato in Design Patterns e ci siamo fermati l&#xEC;. Il libro &#xE8; grosso, ed arrivare in fondo &#xE8; dura. Molti non ce l&#x2019;hanno fatta. Molti si sono accontentati di usare Entities e Value Object per poter dire &#x201C;stiamo facendo DDD&#x201D;. :-/\n\nMolti non sono mai arrivati alla seconda parte del libro.\n
- L&#x2019;ho letto. Lo abbiamo letto. E cosa abbiamo capito? Beh, a tutti &#xE8; piaciuto il concetto di Ubiquitous Language, ma fondamentalmente abbiamo cercato di fare il paio con le pratiche di design che avevamo gi&#xE0; incontrato in Design Patterns e ci siamo fermati l&#xEC;. Il libro &#xE8; grosso, ed arrivare in fondo &#xE8; dura. Molti non ce l&#x2019;hanno fatta. Molti si sono accontentati di usare Entities e Value Object per poter dire &#x201C;stiamo facendo DDD&#x201D;. :-/\n\nMolti non sono mai arrivati alla seconda parte del libro.\n
- L&#x2019;ho letto. Lo abbiamo letto. E cosa abbiamo capito? Beh, a tutti &#xE8; piaciuto il concetto di Ubiquitous Language, ma fondamentalmente abbiamo cercato di fare il paio con le pratiche di design che avevamo gi&#xE0; incontrato in Design Patterns e ci siamo fermati l&#xEC;. Il libro &#xE8; grosso, ed arrivare in fondo &#xE8; dura. Molti non ce l&#x2019;hanno fatta. Molti si sono accontentati di usare Entities e Value Object per poter dire &#x201C;stiamo facendo DDD&#x201D;. :-/\n\nMolti non sono mai arrivati alla seconda parte del libro.\n
- L&#x2019;ho letto. Lo abbiamo letto. E cosa abbiamo capito? Beh, a tutti &#xE8; piaciuto il concetto di Ubiquitous Language, ma fondamentalmente abbiamo cercato di fare il paio con le pratiche di design che avevamo gi&#xE0; incontrato in Design Patterns e ci siamo fermati l&#xEC;. Il libro &#xE8; grosso, ed arrivare in fondo &#xE8; dura. Molti non ce l&#x2019;hanno fatta. Molti si sono accontentati di usare Entities e Value Object per poter dire &#x201C;stiamo facendo DDD&#x201D;. :-/\n\nMolti non sono mai arrivati alla seconda parte del libro.\n
- L&#x2019;ho letto. Lo abbiamo letto. E cosa abbiamo capito? Beh, a tutti &#xE8; piaciuto il concetto di Ubiquitous Language, ma fondamentalmente abbiamo cercato di fare il paio con le pratiche di design che avevamo gi&#xE0; incontrato in Design Patterns e ci siamo fermati l&#xEC;. Il libro &#xE8; grosso, ed arrivare in fondo &#xE8; dura. Molti non ce l&#x2019;hanno fatta. Molti si sono accontentati di usare Entities e Value Object per poter dire &#x201C;stiamo facendo DDD&#x201D;. :-/\n\nMolti non sono mai arrivati alla seconda parte del libro.\n
- L&#x2019;ho letto. Lo abbiamo letto. E cosa abbiamo capito? Beh, a tutti &#xE8; piaciuto il concetto di Ubiquitous Language, ma fondamentalmente abbiamo cercato di fare il paio con le pratiche di design che avevamo gi&#xE0; incontrato in Design Patterns e ci siamo fermati l&#xEC;. Il libro &#xE8; grosso, ed arrivare in fondo &#xE8; dura. Molti non ce l&#x2019;hanno fatta. Molti si sono accontentati di usare Entities e Value Object per poter dire &#x201C;stiamo facendo DDD&#x201D;. :-/\n\nMolti non sono mai arrivati alla seconda parte del libro.\n
- L&#x2019;ho letto. Lo abbiamo letto. E cosa abbiamo capito? Beh, a tutti &#xE8; piaciuto il concetto di Ubiquitous Language, ma fondamentalmente abbiamo cercato di fare il paio con le pratiche di design che avevamo gi&#xE0; incontrato in Design Patterns e ci siamo fermati l&#xEC;. Il libro &#xE8; grosso, ed arrivare in fondo &#xE8; dura. Molti non ce l&#x2019;hanno fatta. Molti si sono accontentati di usare Entities e Value Object per poter dire &#x201C;stiamo facendo DDD&#x201D;. :-/\n\nMolti non sono mai arrivati alla seconda parte del libro.\n
- L&#x2019;ho letto. Lo abbiamo letto. E cosa abbiamo capito? Beh, a tutti &#xE8; piaciuto il concetto di Ubiquitous Language, ma fondamentalmente abbiamo cercato di fare il paio con le pratiche di design che avevamo gi&#xE0; incontrato in Design Patterns e ci siamo fermati l&#xEC;. Il libro &#xE8; grosso, ed arrivare in fondo &#xE8; dura. Molti non ce l&#x2019;hanno fatta. Molti si sono accontentati di usare Entities e Value Object per poter dire &#x201C;stiamo facendo DDD&#x201D;. :-/\n\nMolti non sono mai arrivati alla seconda parte del libro.\n
- L&#x2019;ho letto. Lo abbiamo letto. E cosa abbiamo capito? Beh, a tutti &#xE8; piaciuto il concetto di Ubiquitous Language, ma fondamentalmente abbiamo cercato di fare il paio con le pratiche di design che avevamo gi&#xE0; incontrato in Design Patterns e ci siamo fermati l&#xEC;. Il libro &#xE8; grosso, ed arrivare in fondo &#xE8; dura. Molti non ce l&#x2019;hanno fatta. Molti si sono accontentati di usare Entities e Value Object per poter dire &#x201C;stiamo facendo DDD&#x201D;. :-/\n\nMolti non sono mai arrivati alla seconda parte del libro.\n
- Ok c&#x2019;&#xE8; una parte dell&#x2019;equazione che non abbiamo considerato: il lettore. Io nel 2004 ero un po&#x2019; diverso da adesso. Pi&#xF9; magro probabilmente. Pi&#xF9; ingenuo.\n
- Ok c&#x2019;&#xE8; una parte dell&#x2019;equazione che non abbiamo considerato: il lettore. Io nel 2004 ero un po&#x2019; diverso da adesso. Pi&#xF9; magro probabilmente. Pi&#xF9; ingenuo.\n
- Ok c&#x2019;&#xE8; una parte dell&#x2019;equazione che non abbiamo considerato: il lettore. Io nel 2004 ero un po&#x2019; diverso da adesso. Pi&#xF9; magro probabilmente. Pi&#xF9; ingenuo.\n
- Ok c&#x2019;&#xE8; una parte dell&#x2019;equazione che non abbiamo considerato: il lettore. Io nel 2004 ero un po&#x2019; diverso da adesso. Pi&#xF9; magro probabilmente. Pi&#xF9; ingenuo.\n
- Ok c&#x2019;&#xE8; una parte dell&#x2019;equazione che non abbiamo considerato: il lettore. Io nel 2004 ero un po&#x2019; diverso da adesso. Pi&#xF9; magro probabilmente. Pi&#xF9; ingenuo.\n
- Ok c&#x2019;&#xE8; una parte dell&#x2019;equazione che non abbiamo considerato: il lettore. Io nel 2004 ero un po&#x2019; diverso da adesso. Pi&#xF9; magro probabilmente. Pi&#xF9; ingenuo.\n
- Ok c&#x2019;&#xE8; una parte dell&#x2019;equazione che non abbiamo considerato: il lettore. Io nel 2004 ero un po&#x2019; diverso da adesso. Pi&#xF9; magro probabilmente. Pi&#xF9; ingenuo.\n
- Ok c&#x2019;&#xE8; una parte dell&#x2019;equazione che non abbiamo considerato: il lettore. Io nel 2004 ero un po&#x2019; diverso da adesso. Pi&#xF9; magro probabilmente. Pi&#xF9; ingenuo.\n
- Ok c&#x2019;&#xE8; una parte dell&#x2019;equazione che non abbiamo considerato: il lettore. Io nel 2004 ero un po&#x2019; diverso da adesso. Pi&#xF9; magro probabilmente. Pi&#xF9; 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 &#xE8; che il libro come strumento divulgativo ha qualche controindicazione. E&#x2019; sostanzialmente immutabile: una volta pubblicato ...rimane, mentre la comunit&#xE0; 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&#x2019;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&#xF9; 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 &#xE8; l&#x2019;obiezione pi&#xF9; frequente. Lo sviluppatore frustrato circondato da colleghi espertissimi nell&#x2019;arte del copia ed incolla colleghi espertissimi nell&#x2019;arte del copia ed incolla colleghi espertissimi nell&#x2019;arte del copia ed incolla colleghi espertissimi nell&#x2019;arte del copia ed incolla\n
- Ma suona tanto come un&#x2019;atteggiamento donchisciottesco. Lancia in resta ed all&#x2019;attacco dei mulini a vento.\n
- Probabilmente c&#x2019;&#xE8; qualcosa di importante che non abbiamo capito.\n
- Arriviamo ai giorni nostri. Ne &#xE8; passata di acqua sotto i ponti.\n
- Java, oramai territorio Oracle, non &#xE8; pi&#xF9; una piattaforma cos&#xEC; interessante. A meno di non includere in &#x201C;Java&#x201D; anche linguaggi come Scala, Groovy e JRuby che qualche cosa d&#x2019;interessante da dire ce l&#x2019;hanno.\n
- Java, oramai territorio Oracle, non &#xE8; pi&#xF9; una piattaforma cos&#xEC; interessante. A meno di non includere in &#x201C;Java&#x201D; anche linguaggi come Scala, Groovy e JRuby che qualche cosa d&#x2019;interessante da dire ce l&#x2019;hanno.\n
- L&#x2019;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&#xE0; 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&#x2019;architettura per i comandi ed un&#x2019;architettura per accedere ai dati. Ciascuna ottimizzata senza compromessi. Una figata.\n
- Il concetto di evento di dominio, qualcosa che &#xE8; avvenuto nel sistema, modellato come un verbo al participio passato, diventa un elemento centrale sia della tradizionale architettura DDD sia di quelle pi&#xF9; avveniristiche come CQRS ed Event Sourcing.\n
- Il legame tra TDD e DDD era gi&#xE0; forte nelle fasi iniziali\n
- Ma dalla comunit&#xE0; DDD (in particolare grazie al contributo di Dan North e successivamente di Aslak Hellesoy) nascono strumenti che rivoluzionano l&#x2019;approccio al testing portando al centro del test la necessit&#xE0; 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&#x2019; di pi&#xF9; ad un processo di riferimento. La chiave di volta &#xE8; l&#x2019;uso di differenti strumenti per raffinare continuamente il modello, in modalit&#xE0; &#x201C;pull&#x201D;. \n
- Ma soprattutto, nel 2011 il duetto di Tiziano ferro e Jamelia &#xE8; solo uno sbiadito ricordo.\n
- Purtroppo per&#xF2; sul fronte editoriale non si &#xE8; mosso molto. E le novit&#xE0; hanno un po&#x2019; complicato il quadro. Ci&#xF2; nonostante, i progetti andavano in porto e la comunit&#xE0; DDD era attiva e sempre pi&#xF9; convinta.\n
- Tempo di fare il punto della situazione. Di raccogliere alcuni tra i personaggi pi&#xF9; attivi ed influenti della comunit&#xE0;, per sincronizzarsi e scambiarsi idee in una &#x201C;collaborazione creativa&#x201D; :-)\n
- Ed eccoci qua, in quel di Portland ME a discutere per 3 intensi giorni, di un po&#x2019; di tutto. Tra una camminata per i boschi, una partita di baseball, un&#x2019;interminabile discussione sui Bounded Contexts, ed un po&#x2019; 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 &#xE8; 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 &#xE8; un maiale, la coscia &#xE8; il nostro Core Domain.\n
- L&#x2019;area in cui concentrarci per raggiungere l&#x2019;eccellenza. Perch&#xE9; la qualit&#xE0; in questa zona paga.\n
- Ha senso dedicare le stesse energie alla pancetta? In qualche caso pu&#xF2; 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 &#xE8; sempre pancetta. Come posso capire quali strategia applicare e quando?\n
- E&#x2019; che non si tratta di un problema di architettura software. E&#x2019; un problema business.\n\n
- Che cosa sia core domain &#xE8; determinato essenzialmente dal contesto di mercato in cui ci troviamo. E potr&#xE0; cambiare. E cambier&#xE0;, in maniera indipendente dalla nostra volont&#xE0;.\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&#xF2; che era core, in verde gli aspetti supporting, in giallo quelli generic o comunque non cos&#xEC; strettamente correlati a DDD, mentre in rosso ci&#xF2; che non era DDD.\n
- E questo &#xE8; 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 &#xE8; diventato Cucumber - se ne &#xE8; uscito con un post spettacolare sul concetto di Deliberate Learning. Andatelo a leggere.\n
- E&#x2019; l&#x2019;ignoranza che ci frega. E nel momento di massima ignoranza spesso prendiamo le decisioni pi&#xF9; vincolanti.\n
- E se lavorassimo sull&#x2019;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 &#xE8; una contrapposizione. In DDD &#xE8; un&#x2019;allineamento. Non possiamo produrre software senza imparare, ma non possiamo nemmeno imparare senza produrre software. Testando la nostra capacit&#xE0; di comprendere il dominio.\n
- Ma se il limite &#xE8; l&#x2019;apprendimento allora dobbiamo essere consapevoli di essere ignoranti in materia.\n
- Il vero saggio &#xE8; 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&#x2019;ecosistema &#xE8; importante.\n
- \n
- Apparentemente il nostro contributo pare limitarsi alla formalizzazione di un modello per un dominio complesso. Il punto &#xE8; che in dominii non ancora ben consolidati c&#x2019;&#xE8; un sacco di spazio per l&#x2019;esplorazione e per capire bene cosa sia il modello.\n\nNella realt&#xE0; dei fatti, questo accade anche per dominii consolidati. Dove tutti fanno la stessa cosa e dove un approccio sperimentale pu&#xF2; ribaltare il tavolo e definire un nuovo paradigma. Succede. Succede solo provando. Pu&#xF2; succedere a noi.\n
- Un alto elemento chiave dell&#x2019;approccio &#xE8; quello dell&#x2019;introduzione dei buonded context ad ogni livello della discussione. Non esiste un modello unico. Esiste un contesto in cui questo modello &#xE8; il migliore che conosciamo. Per risolvere un altro problema in un altro contesto, esiste un altro modello.\n
- E ...SORPRESA! DDD non &#xE8; uno stile architetturale o un&#x2019;architettura. Se nel 2004 il Domain Model Pattern era l&#x2019;unica alternativa visibile nel panorama dell&#x2019;epoca, non significa che sia un vincolo irrinunciabile.\n\nIn generale tutto l&#x2019;aspetto dell&#x2019;architettura diventa in DDD supporting. E diverse sono le alternative possibili. Il tutto nel rispetto dei principi e dei valori di DDD.\n
- E&#x2019; interessante notare che in tutti questi approcci, gli aggregati restano centrali.\n\nHo incluso anche DCI... s&#xEC;. Date un&#x2019;occhiata a Qi4J e ne riparliamo.\n
- Ecco un aspetto che &#xE8; 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 &#xE8; probabilmente una scelta strategicamente suicida. Non dimentichiamoci che sono stati fatti passi da gigante in quel settore.\n
- In generale, quello che &#xE8; interessante &#xE8; vedere come esistano differenti approcci alla gestione nella complessit&#xE0; 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&#xE0; &#xE8; nascosta all&#x2019;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&#x2019;argomento) questi sono Touch Points. Dal punto di vista dell&#x2019;applicazione sono Use Case. Sono la stessa cosa. ...non tutti i Touch Points sono Use Case per&#xF2;&#x2026; 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&#xE0; &#xE8; nascosta all&#x2019;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&#x2019;argomento) questi sono Touch Points. Dal punto di vista dell&#x2019;applicazione sono Use Case. Sono la stessa cosa. ...non tutti i Touch Points sono Use Case per&#xF2;&#x2026; 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&#xE0; &#xE8; nascosta all&#x2019;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&#x2019;argomento) questi sono Touch Points. Dal punto di vista dell&#x2019;applicazione sono Use Case. Sono la stessa cosa. ...non tutti i Touch Points sono Use Case per&#xF2;&#x2026; 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&#xE0; &#xE8; nascosta all&#x2019;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&#x2019;argomento) questi sono Touch Points. Dal punto di vista dell&#x2019;applicazione sono Use Case. Sono la stessa cosa. ...non tutti i Touch Points sono Use Case per&#xF2;&#x2026; 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&#xE0; &#xE8; nascosta all&#x2019;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&#x2019;argomento) questi sono Touch Points. Dal punto di vista dell&#x2019;applicazione sono Use Case. Sono la stessa cosa. ...non tutti i Touch Points sono Use Case per&#xF2;&#x2026; 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&#xE0; &#xE8; nascosta all&#x2019;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&#x2019;argomento) questi sono Touch Points. Dal punto di vista dell&#x2019;applicazione sono Use Case. Sono la stessa cosa. ...non tutti i Touch Points sono Use Case per&#xF2;&#x2026; alcune interazioni sono con il cassiere allo sportello, con il treno, etc.\n
- Il punto &#xE8; che ...se c&#x2019;&#xE8; qualcuno oltre a noi che &#xE8; interessato a questioni come l&#x2019;integrit&#xE0; concettuale o alla consistenza del linguaggio attraverso un&#x2019;interazione con la nostra applicazione, questo &#xE8; una persona con cui di solito non parliamo molto: l&#x2019;architetto dell&#x2019;informazione.\n\nOffritegli un caff&#xE8;. Ne vale la pena.\n
- Troppa energia e troppa fatica. Non aspettatevi una nuova edizione del blue book.\n\nMa dovrebbe essere evidente che &#xE8; stato progettato per avere un&#x2019;obsolescenza molto meno rapida di tanti altri. Il focus &#xE8; sui principi, e restano sostanzialmente validi.\n
- E quindi ci limitiamo ad essere una societ&#xE0; segreta che discute sulle interpretazioni di un unico libro?\n
- Non proprio. Uno dei punti forti del Summit &#xE8; stata anche la decisione di uno sforzo collettivo per pubblicare materiale\n
- Date un&#x2019;occhiata al sito ufficiale DDD, stay tuned.\n
- \n
- \n
- E&#x2019; forse stata una delle parti pi&#xF9; difficili del summit. Convergere sul perch&#xE9;.\nIl fatto &#xE8; che ci piace, &#xE8; 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&#x2019;s the answer... If you really like that and think that&#x2019;s the best possible world... then I don&#x2019;t have so much to tell you.\n