Gestire La Complessità Con Domain Driven Design
•Télécharger en tant que KEY, PDF•
7 j'aime•2,600 vues
La presentazione su Domain Driven Design alla V UgiAlt.Net Conference: Milano 23 Gennaio 2010
Recommandé
Contenu connexe
Tendances
Tendances (20)
Plus de Alberto Brandolini
Plus de Alberto Brandolini (20)
Gestire La Complessità Con Domain Driven Design
- 1. Gestire la complessità con Domain Driven Design Alberto Brandolini alberto.brandolini@avanscoperta.it
- 2. About me Nell’IT dai tempi dello ZX Spectrum Generalmente in progetti di grandi dimensioni NonSoloCodice Trainer (Freelance & Skills Matter) Technical Writer Blogger: http://ziobrando.blogspot.com Twitter: ziobrando My e-mail: alberto.brandolini@gmail.com © Alberto Brandolini 2009
- 3. www.avanscoperta.it avanscoperta.wordpress.com alberto.brandolini@avanscoperta.i t © Alberto Brandolini 2009
- 4. Domain Driven Design Il libro di Eric Evans è stato pubblicato nel 2004, e l’interesse è cresciuto di anno in anno. Applicata su progetti: complex enterprise software government performance crytical systems © Alberto Brandolini 2009
- 5. ...direttamente dalla fonte: “Domain-driven design non è una tecnologia o una metodologia. E’ un modo di pensare ed un insieme di priorità volte ad accelerare progetti software in dominii complessi.” © Alberto Brandolini 2009
- 6. Direttamente dalla fonte… part 2 “Se dovessi riscrivere il libro ora, sarebbe completamente diverso” © Alberto Brandolini 2009
- 7. DDD - what it is and why it matters © Alberto Brandolini 2009
- 8. DDD - what it is and why it matters E’ un insieme di tecniche di modellazione collaudata particolarmente indirizzate ad applicazioni complesse. © Alberto Brandolini 2009
- 9. DDD - what it is and why it matters E’ un insieme di tecniche di modellazione collaudata particolarmente indirizzate ad applicazioni complesse. E’ un insieme di principi e pratiche a supporto del processo di sviluppo. © Alberto Brandolini 2009
- 10. DDD - what it is and why it matters E’ un insieme di tecniche di modellazione collaudata particolarmente indirizzate ad applicazioni complesse. E’ un insieme di principi e pratiche a supporto del processo di sviluppo. E’ un insieme di pattern che supportano una visione pulita e coerente del modello del dominio. © Alberto Brandolini 2009
- 11. DDD - what it is and why it matters E’ un insieme di tecniche di modellazione collaudata particolarmente indirizzate ad applicazioni complesse. E’ un insieme di principi e pratiche a supporto del processo di sviluppo. E’ un insieme di pattern che supportano una visione pulita e coerente del modello del dominio. È un insieme di strategie pragmatiche che permettono alle applicazioni di scalare in termini di dimensioni e complessità senza compromettere la loro integrità. © Alberto Brandolini 2009
- 12. ...Non bastava OOP? La proposta iniziale di OOP è stata migliorata in varie direzioni, principalmente indirizzando questioni architetturali e di design. Tuttavia, spesso OOP non è una garanzia di successo, e non è accompagnata da discipline consolidate per modellare dominii complessi. In passato, tool e frameworks hanno “piegato” il paradigma OO introducendo vincoli alla modellazione del dominio. © Alberto Brandolini 2009
- 13. La premessa Il centro dell’attenzione dovrebbe essere sul dominio e sulla sua logica Il la progettazione di un dominio complesso dovrebbe essere basata su un modello © Alberto Brandolini 2009
- 14. L’ecosistema E’ necessario un processo di sviluppo agile, che permetta di raccogliere il feedback di utenti e domain experts, in iterazioni brevi. © Alberto Brandolini 2009
- 15. Cos’hanno in comune queste persone?
- 16. Cos’hanno in comune queste persone?
- 17. Cos’hanno in comune queste persone?
- 18. Cos’hanno in comune queste persone?
- 19. Cos’hanno in comune queste persone?
- 20. Cos’hanno in comune queste persone?
- 21. Cos’hanno in comune queste persone?
- 22. Domain Expert © Alberto Brandolini 2009
- 23. Domain Expert Dominii complessi necessariamente hanno un esperto. © Alberto Brandolini 2009
- 24. Domain Expert Dominii complessi necessariamente hanno un esperto. Non sempre si presenta in “forma canonica” © Alberto Brandolini 2009
- 25. E’ necessario un processo di sviluppo agile, che permetta di raccogliere il feedback di utenti Il domainobiettivo in stabilire e nostro experts, è iterazioni una collaborazione creativa brevi. © Alberto Brandolini 2009
- 26. Product Backlog Feature A Feature B Feature C Feature D Feature E Feature F Feature G Feature H Feature I Feature J © Alberto Brandolini 2009
- 27. Product Backlog Feature A Feature B Do ne ne Do Feature C Feature D Do ne Implemented Features Feature E Feature F Feature G C B Feature H Feature I A Time Feature J Iteration 1 © Alberto Brandolini 2009
- 28. Product Backlog Feature A Feature B ne Do ne Do Feature C Feature D D o ne ne Do Implemented Feature E Features Do ne Feature F Do ne Feature G C F B E Feature H Feature I A D Time Feature J Iteration 1 Iteration 2 © Alberto Brandolini 2009
- 29. Product Backlog Feature A Feature B Do ne Do ne Feature C Feature D o ne D o ne D Implemented Feature E Features ne Feature F Do D o ne Feature G C F Do ne B E H Feature H Feature I ne A D G D o Time Feature J Iteration 1 Iteration 2 Iteration 3 © Alberto Brandolini 2009
- 30. Product Backlog Feature A Feature B Do ne ne Do Feature C Feature D Do ne D o ne Implemented Feature E Features Do ne Feature F Do ne Feature G C F Do ne B E H J Feature H Feature I Do ne o ne A D G I D Time Feature J Iteration 1 Iteration 2 Iteration 3 Iteration 4 ... Do ne © Alberto Brandolini 2009
- 31. Product Backlog Feature A Feature B ne Do ne Do Feature C Feature D Do ne ne Do Implemented Feature E Features o ne Feature F D ne Do Feature G Do ne C F B E H J O q ue r a s a Feature H Feature I ne s t a pp i D o ne Do A è s amo b aD ch gli e at a G I Time ! Feature J Iteration 1 Iteration 2 Iteration 3 Iteration 4 ... Do ne © Alberto Brandolini 2009
- 32. Knowledge Crunching La collaborazione creativa passa necessariamente un processo di apprendimento della complessità del dominio. Siamo interessati, al cosa, al come ed anche al perchè … siamo pagati per imparare © Alberto Brandolini 2009
- 33. E’ necessario un processo di sviluppo agile, che permetta di raccogliere il feedback di utenti e L’apprendimentoin iterazioni domain experts, non è un processo lineare brevi. © Alberto Brandolini 2009
- 34. The right to be wrong © Alberto Brandolini 2009
- 35. Vedere la luce © Alberto Brandolini 2009
- 36. Il Modello
- 37. © Alberto Brandolini 2009
- 38. © Alberto Brandolini 2009
- 39. © Alberto Brandolini 2009
- 40. A cosa serve un modello? Un modello è una rappresentazione del dominio, con uno scopo ben preciso. Non esiste il modello perfetto. Un buon modello è tagliato sull’uso che ne dobbiamo fare. © Alberto Brandolini 2009
- 41. Esprimere il modello Il modello ed il design devono evolvere simultameamente. Model Il codice è la forma di espressione definitiva del modello. Design Manufatti intermedi, diagrammi e documentazione servono per obiettivi intermedi. © Alberto Brandolini 2009
- 42. © Alberto Brandolini 2009
- 43. Cosa stiamo comunicando? © Alberto Brandolini 2009
- 44. Lo-fi UML © Alberto Brandolini 2009
- 45. Lo-fi UML Molti strumenti hanno male interpretato il ruolo di UML, concentrandosi sulle funzionalità di code-generation, reverse engineering, gradazioni di colore, ombre, etc... © Alberto Brandolini 2009
- 46. Lo-fi UML Molti strumenti hanno male interpretato il ruolo di UML, concentrandosi sulle funzionalità di code-generation, reverse engineering, gradazioni di colore, ombre, etc... ma © Alberto Brandolini 2009
- 47. Lo-fi UML Molti strumenti hanno male interpretato il ruolo di UML, concentrandosi sulle funzionalità di code-generation, reverse engineering, gradazioni di colore, ombre, etc... ma Il design è un’attività troppo cruciale per essere condotta in isolamento. © Alberto Brandolini 2009
- 48. Lo-fi UML Molti strumenti hanno male interpretato il ruolo di UML, concentrandosi sulle funzionalità di code-generation, reverse engineering, gradazioni di colore, ombre, etc... ma Il design è un’attività troppo cruciale per essere condotta in isolamento. L’uso di dosi eccessive di UML può impedire agli esperti di dominio di contribuire al modello. © Alberto Brandolini 2009
- 49. Lo-fi UML Molti strumenti hanno male interpretato il ruolo di UML, concentrandosi sulle funzionalità di code-generation, reverse engineering, gradazioni di colore, ombre, etc... ma Il design è un’attività troppo cruciale per essere condotta in isolamento. L’uso di dosi eccessive di UML può impedire agli esperti di dominio di contribuire al modello. © Alberto Brandolini 2009
- 50. Lo-fi UML Molti strumenti hanno male interpretato il ruolo di UML, concentrandosi sulle funzionalità di code-generation, reverse engineering, gradazioni di colore, ombre, etc... ma Il design è un’attività troppo cruciale per essere condotta in isolamento. L’uso di dosi eccessive di UML può impedire agli esperti di dominio di contribuire al modello. Limitiamoci ad un sottoinsieme di UML sufficiente a comunicare con gli esperti di dominio. © Alberto Brandolini 2009
- 51. Analyst Domain Expert Developer Developer Ubiquitous Language Whiteboard discussions Application Code Specs and Test Code documentation © Alberto Brandolini 2009
- 52. Implementiamo il modello: DDD Building Blocks
- 53. Architettura Il contesto di riferimento è dato dal Domain Model Pattern “An object model of the domain that incorporates both behavior and data.” Martin Fowler © Alberto Brandolini 2009
- 54. Presentation Layer Application Layer Qui è dove Domain Layer succedono le cose interessanti Infrastructure Layer © Alberto Brandolini 2009
- 55. Costruiamo il nostro modello Indipendentemente dalla complessità del dominio, il domain model può essere rappresentato con classi, con ruoli e responsabilità. © Alberto Brandolini 2009
- 56. Building blocks In DDD, ogni dominio espone una struttura specifica ma con alcuni tratti comuni. Può quindi essere organizzato in famiglie di classi con scopi ben precisi. Entities Value Objects Services Modules Aggregates Factories Repositories Aggregate Objects Domain Events © Alberto Brandolini 2009
- 57. Entities <<Entity>> Oggetti con un identità Ordine ed uno stato. data cliente Generalmente con una importo controparte su memoria ... persistente. aggiorna(...) Il loro stato evolve, durante chiudi() la vita dell’applicazione. calcolaImporto() ... © Alberto Brandolini 2009
- 58. Value Objects <<Value Object>> VoceOrdine merce Privi del concetto di quantità identità note calcolaImporto() Possono essere <<Value Object>> ... immutabili Money valuta Possono essere importo condivisi tra più entità plus(Money other) minus(Money other) ... © Alberto Brandolini 2009
- 59. Services Rappresenta un’operazione peculiare del domain model. <<Service>> DiscountCalculator Interfaccia definita in ... termini di altri elementi del calcolaScontoApplicabile(Ordine ordine) ... Domain Model L’operazione è stateless Servizi specifici del Dominio appartengono al Domain Layer © Alberto Brandolini 2009
- 60. Aggregates Un raggruppamento di <<Entity>> <<Root>> <<Value Object>> oggetti associati che trattiamo data Ordine VoceOrdine come un’unità di modifica del cliente importo merce quantità note dato. ... aggiorna(...) calcolaImporto() I confini dell’aggregato chiudi() calcolaImporto() ... coincidono con quelli delle ... <<Value Object>> transazione. <<Value Object>> Money Sconto valuta valuta importo importo Un’entità svolge il ruolo di calcolaImporto() plus(Money other) minus(Money other) radice dell’aggregato garantendo annota()... ... l’integrità delle Entity e dei Value Object all’interno dell’aggregato. © Alberto Brandolini 2009
- 61. Factories La creazione di un’istanza di un oggetto complesso non è di <<Factory>> pertinenza dell’oggetto. OrdineFactory ... La gestione della complessità legata alla creaOrdine(...) rigeneraOrdine(...) creazione delle istanze è delegata ad oggetti specifici © Alberto Brandolini 2009
- 62. Repositories Gestiscono le funzionalità di gestione della persistenza, <<Repository>> fornendo l’illusione di una OrdineRepository collezione in memoria. ... trovaOrdiniPendenti(...) Astraggono l’interazione trovaOrdiniEvasi(...) con lo strato di persistenza ... sottostante, offrendo servizi in termini di elementi del domain model. © Alberto Brandolini 2009
- 63. Aggregate Object A volte la responsabilità <<Aggregate Root Object>> dell’integrità dell’intero aggregato è “troppo” per OrdineAggregate l’entità alla radice: può essere ordine necessario un ruolo specifico. ... Un Aggregate Object checkIntegrity(...) coordina il controllo delle reStockOrder() invarianti e la gestione dello ... stato fra le differenti entità dell’aggregato. © Alberto Brandolini 2009
- 64. Domain Event A volte la nostra applicazione tiene traccia di cose che succedono. <<Domain Event>> Simili ai Value Object ma ConsegnaMerce intrinsecamente unici. dove Indipendenti dai confini quando chi transazionali. ... i Domain Event rappresentano eventi che sono significativi all’interno del nostro dominio. © Alberto Brandolini 2009
- 65. Altri mattoncini... Specifications Intention Revealing interfaces Fluent Interfaces Side effect free functions Command Query Separation Closure of Operations ... © Alberto Brandolini 2009
- 66. Mettendo tutto assieme... Aggregate Repository Factory usa salva crea Specification verifica Entity Value Object Value Object Value Object © Alberto Brandolini 2009
- 67. Mettendo tutto assieme... Presi uno ad uno questi pattern non sono una rivoluzione. Sono stati selezionati fra progetti di successo, non inventati. Nel loro insieme forniscono un approccio scalabile per gestire dominii complessi. Producono un design duttile in grado di reagire al cambiamento ed alle evoluzioni © Alberto Brandolini 2009
- 68. Aggregate Repository Factory Aggregate Repository Factory usa Service usa salva crea usa crea salva Specification verifica Entity Specification verifica Entity Entity Value Object Value Object Value Object Value Object usa Value Object Value Object Service Repository usa Value Object Domain salva Repository Event salva Entity Entity Entity usa Value Object Value Object usa Value Object Value Object Specification © Alberto Brandolini 2009
- 70. Complessità
- 71. Domain Complexity © Alberto Brandolini 2009
- 72. Domain Complexity © Alberto Brandolini 2009
- 73. Domain Complexity © Alberto Brandolini 2009
- 74. Evolution Cost Domain Complexity © Alberto Brandolini 2009
- 75. Evolution Cost Domain Complexity © Alberto Brandolini 2009
- 76. A l c re s c e re de de l d o m l la c o m i n io, i p ple s s i t tradiz a radi g à io n a l i “ mi s of f ro n o” Evolution Cost Domain Complexity © Alberto Brandolini 2009
- 77. Evolution Cost Domain Complexity © Alberto Brandolini 2009
- 78. Evolution Cost Domain Complexity © Alberto Brandolini 2009
- 79. Evolution Cost “ Ta cti c a l DDD ” s c a la b è i l e r i sp c o mp le etto a l s s i tà d la el Do m i n io Domain Complexity © Alberto Brandolini 2009
- 80. Evolution Cost Domain Complexity © Alberto Brandolini 2009
- 81. Domain Complexity © Alberto Brandolini 2009
- 82. Domain Complexity © Alberto Brandolini 2009
- 83. Domain Complexity Pr o je ct Siz e( LO C) © Alberto Brandolini 2009
- 84. Domain Complexity Pr o je ct Siz e( LO C) © Alberto Brandolini 2009
- 85. e) (t i m i ze ts je c Pro Domain Complexity Pr o je ct Siz e( LO C) © Alberto Brandolini 2009
- 86. e) (t i m i ze ts je c Pro Domain Complexity Pr o je ct Siz e( LO C) © Alberto Brandolini 2009
- 87. e) Ex (t i m te rn al i ze Sy o st r L ts em e g je c s ac y Pro Domain Complexity Pr o je ct Siz e( LO C) © Alberto Brandolini 2009
- 88. e) Ex (t i m te rn al i ze Sy o st r L ts em e g je c s ac y Pro Domain Complexity Pr o je ct Siz e( LO C) © Alberto Brandolini 2009
- 89. e) Ex (t i m te rn al i ze Sy o st r L ts em e g je c s ac y Pro Domain Complexity Pr e Siz o je ct m Siz Te a e( LO C) © Alberto Brandolini 2009
- 90. e) Ex (t i m te rn al i ze Sy o st r L ts em e g je c s ac y Pro Domain Complexity Pr e Siz o je ct m Siz Te a e( LO C) © Alberto Brandolini 2009
- 91. e) Ex (t i m te rn al i ze Sy o st r L ts em e g je c s ac y Pro t io n iza y Domain Complexity g an e x i t Or pl C om Pr e Siz o je ct m Siz Te a e( LO C) © Alberto Brandolini 2009
- 92. © Alberto Brandolini 2009
- 93. Il successo è uno dei fattori di incremento della complessità © Alberto Brandolini 2009
- 94. Il successo è uno dei fattori di incremento della complessità © Alberto Brandolini 2009
- 95. Il successo è uno dei fattori di incremento della complessità © Alberto Brandolini 2009
- 96. L’illusione del foglio bianco ...Siamo nel 2010 ...seriamente pensiamo che il nostro cliente non abbia mai usato i computer? © Alberto Brandolini 2009
- 97. Bounded Context L’integrità di un modello può essere garantita solo “entro certi limiti” Bounded Context Un bounded context rappresenta la massima estensione di un modello di cui possiamo garantire l’integrità © Alberto Brandolini 2009
- 98. Contesto “il luogo che determina il significato di un termine che vi compare”
- 99. Termine e significato © Alberto Brandolini 2009
- 100. Termine e significato Cappuccino © Alberto Brandolini 2009
- 101. Termine e significato Cappuccino © Alberto Brandolini 2009
- 102. Termine e significato Cappuccino © Alberto Brandolini 2009
- 103. Termine e significato Cappuccino © Alberto Brandolini 2009
- 104. Termine e significato Cappuccino Cappuccino © Alberto Brandolini 2009
- 105. Termine e significato Cappuccino Cappuccino © Alberto Brandolini 2009
- 106. Termine e significato Cappuccino Cappuccino ? © Alberto Brandolini 2009
- 107. Termine e significato Cappuccino Cappuccino ? © Alberto Brandolini 2009
- 108. Termine e significato Cappuccino Cappuccino ? Cappuccino © Alberto Brandolini 2009
- 109. Termine e significato Cappuccino Cappuccino ? Cappuccino © Alberto Brandolini 2009
- 110. Termine e significato Cappuccino Cappuccino ? Cappuccino ? © Alberto Brandolini 2009
- 111. Termine e significato Cappuccino Cappuccino ? Cappuccino ? © Alberto Brandolini 2009
- 112. Termine e significato Cappuccino Cappuccino ? Cappuccino ? Cappuccino © Alberto Brandolini 2009
- 113. Termine e significato Cappuccino Cappuccino ? Cappuccino ? Cappuccino ? © Alberto Brandolini 2009
- 114. Interludio: Breve storia di una lingua (liberamente interpretata) © Alberto Brandolini 2009
- 115. Il modello originale è il risultato di diverse influenze © Alberto Brandolini 2009
- 116. Una reference implementation ha permesso di stabilire uno standard © Alberto Brandolini 2009
- 117. L’adozione su larga scala ha introdotto delle variazioni © Alberto Brandolini 2009
- 118. Un sottoinsieme del modello è diventato una lingua franca permettendo interoperabilità fra sistemi differenti © Alberto Brandolini 2009
- 119. Nonostante gli sforzi per produrre una documentazione estensiva l’evoluzione non si arresta © Alberto Brandolini 2009
- 120. Alcuni non aderiscono agli standard © Alberto Brandolini 2009
- 121. Alcuni non aderiscono agli standard © Alberto Brandolini 2009
- 122. Alcuni non ... e forse aderiscono non lo agli faranno standard mai © Alberto Brandolini 2009
- 123. Nuovi requisiti e/o canali di comunicazione possono introdurre cambiamenti anche in contesti consolidati © Alberto Brandolini 2009
- 124. Multiple models Web Application Context Banking Context Account Account La consapevolezza della presenza di più modelli, può aiutarci ad avere una visione d’insieme più nitida Copyright Alberto Brandolini
- 125. Multiple models Applicazioni non banali hanno sempre a che fare con più modelli Applicazioni complesse svolgono in genere più di un compito dominii complessi possono essere territorio di diversi esperti di dominio © Alberto Brandolini 2009
- 126. Team A Team B Organization Level e r on t One h e e re n p r i m te am e ot ff a r i l wo r e t h a di y k c l a s o n s om s hi l s o n rt io n se s e . . .w o r k p o w A' Context Level A ...c be onc c om e p slo e s e t ua l wl xp int y s en eg li p si v r i t sa ea y wa n d y Copyright Alberto Brandolini
- 127. Relazioni fra contesti la complessità si annida nel modo in cui differenti contesti sono in relazione tra loro Context Context © Alberto Brandolini 2009
- 128. Relazioni fra contesti la complessità si annida nel modo in cui differenti contesti sono in relazione tra loro Con xt © Alberto Brandolini 2009
- 129. Upstream-Downstream u Context B Context A d © Alberto Brandolini 2009
- 130. Il software rispecchia le organizzazioni
- 131. Strategic DDD Patterns Anti Corruption Layer Conformist Customer Supplier Partnership Open Host Published Language Continuous Integration Separate Ways Shared Kernel Big Ball Of Mud © Alberto Brandolini 2009
- 132. Tactical DDD Strategic DDD Patterns da applicare al Pattern da riconoscere design della nostra nello scenario di progetto applicazione applicabili in un riconoscibili in ogni ecosistema ben ecosistema definito Design duttile ...Context Map? Copyright Alberto Brandolini
- 133. Our context map Big Ba l l of Mu d Context Context F C ! u Context A AC d pe n L d O Hos t Context u B Context Context E D
- 134. © Alberto Brandolini 2009
- 135. Strategic Domain Driven Design
- 137. “Le battaglie sono vinte prima di essere combattute” Sun Tzu
- 138. “Le battaglie sono vinte prima di essere combattute” Sun Tzu “La tattica senza strategia è solo rumore prima della sconfitta” Sun Tzu
- 139. Modello a risorse finite Progetti complessi richiedono una corretta valutazione dello scenario in cui operiamo. Le risorse disponibili per un progetto non sono infinite
- 140. Un gioco di strategia? © Alberto Brandolini 2009
- 141. Un gioco di strategia? • Money • Brain • Time • Developers • Skills © Alberto Brandolini 2009
- 142. Un gioco di strategia? • Money • Brain • Time • Developers • Skills © Alberto Brandolini 2009
- 143. Un gioco di strategia? • Money • Brain • Time • Developers • Skills © Alberto Brandolini 2009
- 144. Un gioco di strategia? • Money • Brain • Time • Developers • Skills © Alberto Brandolini 2009
- 145. Un gioco di strategia? • Money • Brain • Time • Developers • Skills © Alberto Brandolini 2009
- 146. Un gioco di strategia? • Money • Brain • Time • Developers • Skills © Alberto Brandolini 2009
- 147. Un gioco di strategia? • Money • Brain • Time • Developers • Skills © Alberto Brandolini 2009
- 148. Un gioco di strategia? • Money • Brain • Time • Developers • Skills © Alberto Brandolini 2009
- 149. Un gioco di strategia? • Money • Brain • Time • Developers • Skills © Alberto Brandolini 2009
- 150. Un gioco di strategia? • Money • Brain • Time • Developers • Skills © Alberto Brandolini 2009
- 151. Un gioco di strategia? • Money • Brain • Time • Developers • Skills © Alberto Brandolini 2009
- 152. Un gioco di strategia? • Money • Brain • Time • Developers • Skills © Alberto Brandolini 2009
- 153. Un gioco di strategia? • Money • Brain • Time • Developers • Skills © Alberto Brandolini 2009
- 154. Un gioco di strategia? • Money • Brain • Time • Developers • Skills © Alberto Brandolini 2009
- 155. Un gioco di strategia? • Money • Brain • Time • Developers • Skills © Alberto Brandolini 2009
- 156. Un gioco di strategia? • Money • Brain • Time • Developers • Skills © Alberto Brandolini 2009
- 157. Un gioco di strategia? • Money • Brain • Time • Developers • Skills © Alberto Brandolini 2009
- 158. Un gioco di strategia? • Money • Brain • Time • Developers • Skills © Alberto Brandolini 2009
- 159. Un gioco di strategia? • Money • Brain • Time • Developers • Skills © Alberto Brandolini 2009
- 160. Un gioco di strategia? • Money • Brain • Time • Developers • Skills © Alberto Brandolini 2009
- 161. Un gioco di strategia? • Money • Brain • Time • Developers • Skills © Alberto Brandolini 2009
- 162. Un gioco di strategia? • Money • Brain • Time • Developers • Skills © Alberto Brandolini 2009
- 163. Le dimensioni contano Dominii di grandi dimensioni o particolarmente complessi non possono essere gestiti allo stesso modo: - più scopi non sempre convergenti - la comunicazione è meno efficiente al crescere della dimensione del team - gli sforzi per mantenere una visione coerente possono risultare superiori ai benefici © Alberto Brandolini 2009
- 164. Molte organizzazioni ipotizzano un modello ottimistico di condivisione
- 165. Molte organizzazioni ipotizzano un modello ottimistico di condivisione
- 166. Ma la realtà è decisamente diversa
- 167. Quanto costa mettersi d’accordo?
- 168. ...per non parlare della gestione delle risorse umane
- 169. Ma noi sappiamo che le risorse non sono
- 170. Ma noi sappiamo che le risorse non sono
- 171. La cosa giusta
- 172. Cosa ci rende speciali?
- 174. Benefici e costi © Alberto Brandolini 2009
- 175. Come scegliere? Allochiamo le nostre risorse laddove possano apportare i maggiori benefici Non investiamo oltre il necessario in aree che introducono vantaggi marginali (qual è il ruolo della tecnologia in questo scenario?) © Alberto Brandolini 2009
- 176. … serve una Mappa © Alberto Brandolini 2009
- 177. Un bagno di realtà Non tutte la parti di un’applicazione non banale saranno progettate ugualmente bene ...ma alcune parti del sistema sono più importanti di altre © Alberto Brandolini 2009
- 178. Core Domain Specifico del nostro dominio applicativo. Il nucleo centrale dell’applicazione, le cui funzionalità ci assicurano un vantaggio competitivo. © Alberto Brandolini 2009
- 179. Supporting Subdomain legato al dominio applicativo, ma non in grado di garantire un vantaggio in termini di competitività. © Alberto Brandolini 2009
- 180. Generic Subdomain Non particolarmente legato al dominio applicativo, necessario al funzionamento complessivo dell’applicazione. © Alberto Brandolini 2009
- 181. Priorità Le priorità provengono dal contesto business ...e cambieranno… Per produrre software che faccia la differenza dovremo capire cosa fa la differenza © Alberto Brandolini 2009
- 182. References Domain Driven Design Eric Evans http://domaindrivendesign.org http://tech.groups.yahoo.com/group/ domaindrivendesign http://it.groups.yahoo.com/group/DDD-IT http://www.infoq.com/articles/ddd- contextmapping © Alberto Brandolini 2009
- 183. References Apply Domain Driven Design and Patterns Jimmy Nilsson Addison Wesley © Alberto Brandolini 2009
- 184. Domain Driven Design discussion groups • http://tech.groups.yahoo.com/group/ domaindrivendesign/ • http://it.groups.yahoo.com/group/DDD-IT/ © Alberto Brandolini 2009
- 185. Questions? © Alberto Brandolini 2009
Notes de l'éditeur
- Tutto &#xE8; partito dal libro,
- La definizione originale &#xE8; in qualche modo sfuggente: non si tratta di una metodologia con regole precise. Si tratta di qualcosa di meno strutturato: un approccio o un atteggiamento nei confronti dello sviluppo software.
- Tuttavia nella cassetta degli attrezzi di domain driven design troviamo una serie di strumenti di grande utilit&#xE0; che permettono di migliorare notevolmente l&#x2019;efficacia del nostro approccio alo sviluppo del software.
- Tuttavia nella cassetta degli attrezzi di domain driven design troviamo una serie di strumenti di grande utilit&#xE0; che permettono di migliorare notevolmente l&#x2019;efficacia del nostro approccio alo sviluppo del software.
- Tuttavia nella cassetta degli attrezzi di domain driven design troviamo una serie di strumenti di grande utilit&#xE0; che permettono di migliorare notevolmente l&#x2019;efficacia del nostro approccio alo sviluppo del software.
- Tuttavia nella cassetta degli attrezzi di domain driven design troviamo una serie di strumenti di grande utilit&#xE0; che permettono di migliorare notevolmente l&#x2019;efficacia del nostro approccio alo sviluppo del software.
- La gestione di contesti complessi &#xE8; stata negli anni passati il cavallo di battaglia di OOP. Tutto l&#x2019;impianto teorico di OOP nasceva per una corretta gestione della complessit&#xE0;. Tuttavia alcune delle buzzword - il mito del riuso per citarne uno - non hanno mantenuto le promesse iniziali. Soluzioni realmente riusabili sono apparse successivamente, in forma di patterns (GoF, GRASP, POSA, PEAA etc&#x2026;). Il focus &#xE8; stato principalmente sull&#x2019;architettura: la neutralit&#xE0; rispetto al dominio garantiva infatti una maggiore riusabilit&#xE0;. L&#x2019;unica eccezione notevole degli ultimi anni a questo trend &#xE8; stato il libro di Martin Fowler Analysis Patterns.
- Questa ovviamente non &#xE8; una premessa per qualsiasi progetto: &#xE8; tuttavia lo scenario pi&#xF9; adatto per applicare i principi di Domain Driven Design. O meglio quelli di &#x201C;Tactical Domai Driven Design&#x201D; (la differenza sar&#xE0; pi&#xF9; chiara in seguito). C&#x2019;&#xE8; comunque una scelta strategica di fondo. Un dominio complesso non pu&#xF2; essere catturato a costo zero, il lavoro di ricerca ha un costo che si ripaga fornendo un vantaggio competitivo. Inoltre si tratta di un asset che ha valore nel tempo e pertanto va mantenuto indipendente dalla tecnologia circostante che varia secondo ritmi e forze completamente differenti.
- Domain driven design pu&#xF2; avvenire in un contesto ben preciso, solo se determinate condizioni sono verificate. Questo ecosistema &#xE8; relativamente fragile e presuppone un contesto fortemente collaborativo che favorisca la creativit&#xE0;. Un contesto di sviluppo agile &#xE8; necessario in particolare per una caratteristica che accomuna tutte le metodologie, ovvero l&#x2019;esasperata ricerca del feedback, in ogni sua forma.
- Giuliano Moggi, Giulio Andreotti, Licio Gelli, Giuseppe Cossiga, Tommaso Buscetta, Hannibal Lecter. Cos&#x2019;hanno in comune queste persone?
- Giuliano Moggi, Giulio Andreotti, Licio Gelli, Giuseppe Cossiga, Tommaso Buscetta, Hannibal Lecter. Cos&#x2019;hanno in comune queste persone?
- Giuliano Moggi, Giulio Andreotti, Licio Gelli, Giuseppe Cossiga, Tommaso Buscetta, Hannibal Lecter. Cos&#x2019;hanno in comune queste persone?
- Giuliano Moggi, Giulio Andreotti, Licio Gelli, Giuseppe Cossiga, Tommaso Buscetta, Hannibal Lecter. Cos&#x2019;hanno in comune queste persone?
- Giuliano Moggi, Giulio Andreotti, Licio Gelli, Giuseppe Cossiga, Tommaso Buscetta, Hannibal Lecter. Cos&#x2019;hanno in comune queste persone?
- Giuliano Moggi, Giulio Andreotti, Licio Gelli, Giuseppe Cossiga, Tommaso Buscetta, Hannibal Lecter. Cos&#x2019;hanno in comune queste persone?
- Si tratta di esperti di dominio (e che avevate pensato&#x2026;). Si tratta di persone che sanno un sacco di cose, cose che ci interessano ma che non &#xE8; detto che siano cos&#xEC; inclini a rivelare. Conoscono la loro materia ad un livello profondo e sono in grado di dirci i perch&#xE8;. Il canale di comunicazione con l&#x2019;esperto di dominio &#xE8; forse il single point of failure pi&#xF9; delicato di tutto l&#x2019;impianto di DDD. Siamo interessati ad una collaborazione creativa, difficile, ma preziosa ed incredibilmente potente.
- Si tratta di esperti di dominio (e che avevate pensato&#x2026;). Si tratta di persone che sanno un sacco di cose, cose che ci interessano ma che non &#xE8; detto che siano cos&#xEC; inclini a rivelare. Conoscono la loro materia ad un livello profondo e sono in grado di dirci i perch&#xE8;. Il canale di comunicazione con l&#x2019;esperto di dominio &#xE8; forse il single point of failure pi&#xF9; delicato di tutto l&#x2019;impianto di DDD. Siamo interessati ad una collaborazione creativa, difficile, ma preziosa ed incredibilmente potente.
- Il nostro lavoro &#xE8; in larga parte un percorso di apprendimento. Siamo pagati per imparare i risvolti pi&#xF9; nascosti del dominio. Con ogni mezzo disponibile&#x2026; (possiamo essere creativi anche nell&#x2019;apprendimento)
- L&#x2019;apprendimento non &#xE8; un processo lineare, passa attraverso errori e ravvedimenti. Non &#xE8; detto che questo corrisponda ad un&#x2019;accumulazione di story points iterazione dopo iterazione in un modo statisticamente prevedibile. Breakthrough s refactoring sono gli strumenti che ci permettono di fare evolvere la nostra applicazione verso una conoscenza del dominio sempre pi&#xF9; raffinata.
- L&#x2019;obiettivo &#xE8; la realizzazione di un modello. Cosa intendiamo esattamente?
- La mappa della metropolitana di Londra. Utilissima per chi si muove nella grande metropoli. La rappresentazione NON &#xE8; fedele, il Tamigi sicuramente non &#xE8; ad angoli retti, ma ci&#xF2; non compromette l&#x2019;utilit&#xE0; dello strumento.
- Un&#x2019;altra mappa di Londra, via google maps. Il dominio mappato &#xE8; lo stesso, con fedelt&#xE0; maggiore. Il focus in questo caso &#xE8; sulla rete stradale.
- Un&#x2019;ulteriore mappa sempre riferita allo stesso dominio. Il livello di dettaglio e la fedelt&#xE0; &#xE8; sicuramente maggiore. Ma l&#x2019;utilit&#xE0; per un utente della metropolitana &#xE8; decisamente inferiore.
- Questa cosa del modello perfetto &#xE8; stata per anni una perversione degli analisti OOP. Il succo del ragionamento era (ci sono passato anche io&#x2026;) &#x201C;Se gestisco un numero sufficiente di casistiche allora il mio modello potr&#xE0; essere riutilizzato anche in altri contesti&#x201D;. &#xC8; l&#x2019;uso a definire le caratteristiche e la conseguente utilit&#xE0; del modello. Il modello serve a qualcosa. Capire a cosa ci aiuta nella costruzione del modello pi&#xF9; adatto.
- Esiste una sola rappresentazione del modello che ci garantisce l&#x2019;allineamento con il comportamento del sistema. Il codice. Tutto il resto serve ad uno scopo intermedio.
- Una rappresentazione UML pu&#xF2; tornare utile in determinati contesti, ma controproducente in altri. UML &#xE8; uno strumento di comunicazione, e se finisce per introdurre una barriera che ostacola la comunicazione allora pu&#xF2; darsi che non sia lo strumento adatto. In ogni caso il contenuto della comunicazione e l&#x2019;efficienza del canale sono immensamente pi&#xF9; importanti del linguaggio in cui il contenuto viene espresso.
- In alcuni casi, l&#x2019;uso/abuso di UML ha piegato il processo di sviluppo distogliendolo dai suoi obiettivi primari. Un sottoinsieme ragionato di UML utilizzato alla lavagna come strumento di supporto ad un ragionamento condiviso &#xE8; probabilmente il compromesso migliore. Il design &#xE8; un&#x2019;attivit&#xE0; che implica confronto. Se avviene in isolamento non &#xE8; decisamente un buon segnale.
- In alcuni casi, l&#x2019;uso/abuso di UML ha piegato il processo di sviluppo distogliendolo dai suoi obiettivi primari. Un sottoinsieme ragionato di UML utilizzato alla lavagna come strumento di supporto ad un ragionamento condiviso &#xE8; probabilmente il compromesso migliore. Il design &#xE8; un&#x2019;attivit&#xE0; che implica confronto. Se avviene in isolamento non &#xE8; decisamente un buon segnale.
- In alcuni casi, l&#x2019;uso/abuso di UML ha piegato il processo di sviluppo distogliendolo dai suoi obiettivi primari. Un sottoinsieme ragionato di UML utilizzato alla lavagna come strumento di supporto ad un ragionamento condiviso &#xE8; probabilmente il compromesso migliore. Il design &#xE8; un&#x2019;attivit&#xE0; che implica confronto. Se avviene in isolamento non &#xE8; decisamente un buon segnale.
- In alcuni casi, l&#x2019;uso/abuso di UML ha piegato il processo di sviluppo distogliendolo dai suoi obiettivi primari. Un sottoinsieme ragionato di UML utilizzato alla lavagna come strumento di supporto ad un ragionamento condiviso &#xE8; probabilmente il compromesso migliore. Il design &#xE8; un&#x2019;attivit&#xE0; che implica confronto. Se avviene in isolamento non &#xE8; decisamente un buon segnale.
- In alcuni casi, l&#x2019;uso/abuso di UML ha piegato il processo di sviluppo distogliendolo dai suoi obiettivi primari. Un sottoinsieme ragionato di UML utilizzato alla lavagna come strumento di supporto ad un ragionamento condiviso &#xE8; probabilmente il compromesso migliore. Il design &#xE8; un&#x2019;attivit&#xE0; che implica confronto. Se avviene in isolamento non &#xE8; decisamente un buon segnale.
- In alcuni casi, l&#x2019;uso/abuso di UML ha piegato il processo di sviluppo distogliendolo dai suoi obiettivi primari. Un sottoinsieme ragionato di UML utilizzato alla lavagna come strumento di supporto ad un ragionamento condiviso &#xE8; probabilmente il compromesso migliore. Il design &#xE8; un&#x2019;attivit&#xE0; che implica confronto. Se avviene in isolamento non &#xE8; decisamente un buon segnale.
- Il meccanismo di controllo - la prova del 9 - sul fatto che le cose stiano andando nel verso giusto &#xE8; rappresentato dallo Ubiquitous Language. Non deve esistere alcun passaggio di traduzione. I concetti espressi a livello di conversazione con l&#x2019;esperto di dominio devono avere una loro controparte a livello di codice. Ogni termine deve essere semanticamente definito con precisione. L&#x2019;ambiguit&#xE0; &#xE8; il nostro peggior nemico.
- Come costruire il modello in un generico linguaggio ad oggetti? Java, C# etc...
- Un vero domain model &#xE8; necessario. Si tratta di un paradigma architetturale noto da tempo ma che ha conosciuto alterne fortune. &#xC8; interessante notare la caratterizzazione che ne da Fowler: &#xE8; pi&#xF9; difficile da ottenere, ma una volta che gli sviluppatori prendono dimestichezza, non tornano pi&#xF9; indietro. Si tratta in ogni caso di uno strumento raffinato che richiede una certa padronanza dei principi fondamentali di OOP.
- Architetturalmente questo definisce un luogo ben preciso dove accadono le cose: il domain layer. Uno strato completamente indipendente dalla tecnologia dove concentrarsi unicamente sulla realizzazione di un modello utile ed efficace.
- I principi di ragionamento di DDD non differiscono di molto da quelli classici della OOP: c&#x2019;&#xE8; la proposta di archetipi ripetibili ed un pragmatismo di fondo che mitiga alcuni estremismi.
- Questa &#xE8; senza dubbio la parte pi&#xF9; famosa di DDD. Molti lettori non hanno superato la met&#xE0; del libro. Si tratta di mattoncini utili per la costruzione di un modello di dominio equilibrato e coerente.
- Notare la genericit&#xE0; dei termini, non ho detto database. In ogni caso, il focus non &#xE8; tanto la corrispondenza delle classi con un a tabella sul database (che potrebbe dare adito ad un anemic domain model), quanto il fatto che l&#x2019;applicazione tiene traccia del ciclo di vita delle nostre entit&#xE0;. Per certi versi l&#x2019;intera applicazione non &#xE8; altro che una gestione delle transizioni di stato delle nostre entit&#xE0;.
- I Value Objects sono componenti decisamente pi&#xF9; semplici: la loro caratteristica pi&#xF9; importante &#xE8; l&#x2019;immutabilit&#xE0;. Non evolvono e questo rappresenta una drastica semplificazione del software necessario a gestirli.
- I services rappresentano azioni caratteristiche del dominio. Spesso sono punti di accesso a complessit&#xE0; che avviene in altre parti dell&#x2019;applicazione. Imporre una gestione stateless semplifica grandemente la scalabilit&#xE0;.
- Gli aggregati rappresentano un insieme di classi con un&#x2019;unit&#xE0; logica complessiva. I confini dell&#x2019;aggregato (non stiamo parlando di aggregazione UML) coincidono spesso con quelle della propagazione della cancellazione, con i confini transazionali, con un unit&#xE0; di trasporto significativa nel caso di applicazioni distribuite.
- Anche in questo caso non stiamo parlando di un Pattern specifico. GoF sviscera il tema dei Factory giungendo in alcuni casi alla perversione. In DDD l&#x2019;enfasi non &#xE8; sulle meccaniche o sul come implementare un factory, quanto sul fatto che la creazione di un oggetto rappresenti una responsabilit&#xE0; che &#xE8; logicamente svincolata dagli altri compiti della classe, quindi &#xE8; bene che sia esternalizzata. Diversi supporti tecnologici possono aiutarci in misura diversa in questo campo (es. Dependency Injection).
- Un repository &#xE8; il punto di confine tra il nostro Domain Model ed il mondo della persistenza. Ci sono (almeno) due linguaggi che agiscono nello stesso punto (OO, SQL, ORM specific&#x2026; ). Il Repository dovrebbe astrarre rispetto alla complessit&#xE0; e gestire le operazioni di persistenza ad un livello logico. In alcuni casi il disaccoppiamento logico che viene ottenuto pu&#xF2; non risultare un vantaggio determinante, ma l&#x2019;introduzione di differenti strategie di persistenza alternative al RDBMS ha riaperto i giochi anche in questa porzione dell&#x2019;applicazione.
- Si tratta di un&#x2019;aggiunta rispetto alla formulazione del libro. In alcuni casi, la complessit&#xE0; dell&#x2019;aggregato da rendere necessario un ruolo di coordinamento dell&#x2019;intera struttura, in una classe a parte.
- Anche in questo caso si tratta di una new entry. Alcuni eventi caratteristici del sistema sono immutabili (come i VO) ma con un&#x2019;identit&#xE0; molto chiara (come le entity). I Doain Event colmano questa lacuna.
- Per arrivare alla costruzione del nostro design duttile, altri elementi entreranno in ballo. Influenzando largamente il nostro stile di scrittura trasformando il nostro codice in qualcosa di molto simile ad un DSL. In alcuni linguaggi questo sar&#xE0; pi&#xF9; facile che in altri, ma il succo &#xE8; la possiblit&#xE0; di poter disporre di uno srumento duttile e potente tra le mani che accorci la distanza tra pensiero (del domain expert) ed azione (dell&#x2019;applicazione)
- L&#x2019;effetto combinato dei vari pattern &#xE8; decisamente interessante. Si tratta di una struttura emergente con caratteristiche ripetibili.
- La caratteritica pi&#xF9; interessante &#xE8; che determinate complicazioni insite nel dominio semplicemente smettono di presentarsi. Il dominio risulta gi&#xE0; &#x201C;pettinato&#x201D; prima di costruirci un&#x2019;applicazione sopra. La struttura risultante &#xE8; logicamente ordinata.
- Sono famiglie, archetipi ripetibili. Non tutte le famiglie hanno tutti i nonni. non tutte le famiglie hanno 2 figli ma siamo in grado di riconoscere le famiglie e di comprendere la suddivisione dei ruoli al loro interno.
- Si tratta di un meccanismo che permette di scalare il nostro domain model, mentre le formulazioni classiche finivano prima o poi per incartarsi. Con DDD riesco ad andare oltre&#x2026; ma di quanto?
- Per capire meglio cosa succede nel passaggio dalla teoria alla pratica dobbiamo cambiare approccio e prospettiva.
- Gli strumenti appena visti ci permettono di gestire la complessit&#xE0; del dominio applicativo &#x201C;senza incartarci&#x201D;, ottenendo un modello flessibile in grado di seguire le mutevoli esigenze del business, senza ostacolarlo o rallentarlo.
- Gli strumenti appena visti ci permettono di gestire la complessit&#xE0; del dominio applicativo &#x201C;senza incartarci&#x201D;, ottenendo un modello flessibile in grado di seguire le mutevoli esigenze del business, senza ostacolarlo o rallentarlo.
- Gli strumenti appena visti ci permettono di gestire la complessit&#xE0; del dominio applicativo &#x201C;senza incartarci&#x201D;, ottenendo un modello flessibile in grado di seguire le mutevoli esigenze del business, senza ostacolarlo o rallentarlo.
- Gli strumenti appena visti ci permettono di gestire la complessit&#xE0; del dominio applicativo &#x201C;senza incartarci&#x201D;, ottenendo un modello flessibile in grado di seguire le mutevoli esigenze del business, senza ostacolarlo o rallentarlo.
- Gli strumenti appena visti ci permettono di gestire la complessit&#xE0; del dominio applicativo &#x201C;senza incartarci&#x201D;, ottenendo un modello flessibile in grado di seguire le mutevoli esigenze del business, senza ostacolarlo o rallentarlo.
- Gli strumenti appena visti ci permettono di gestire la complessit&#xE0; del dominio applicativo &#x201C;senza incartarci&#x201D;, ottenendo un modello flessibile in grado di seguire le mutevoli esigenze del business, senza ostacolarlo o rallentarlo.
- Gli strumenti appena visti ci permettono di gestire la complessit&#xE0; del dominio applicativo &#x201C;senza incartarci&#x201D;, ottenendo un modello flessibile in grado di seguire le mutevoli esigenze del business, senza ostacolarlo o rallentarlo.
- Gli strumenti appena visti ci permettono di gestire la complessit&#xE0; del dominio applicativo &#x201C;senza incartarci&#x201D;, ottenendo un modello flessibile in grado di seguire le mutevoli esigenze del business, senza ostacolarlo o rallentarlo.
- Gli strumenti appena visti ci permettono di gestire la complessit&#xE0; del dominio applicativo &#x201C;senza incartarci&#x201D;, ottenendo un modello flessibile in grado di seguire le mutevoli esigenze del business, senza ostacolarlo o rallentarlo.
- Per&#xF2; il modello a cui facciamo riferimento &#xE8; oltremodo semplificato. Un solo progetto, un solo team. La complessit&#xE0; dei progetti reali in realt&#xE0; pu&#xF2; essere molto diversa e costringerci ad affrontare i problemi dello sviluppo software con un occhio pragmatico e rivolto alla sostenibilit&#xE0; delle nostre scelte.
- Per&#xF2; il modello a cui facciamo riferimento &#xE8; oltremodo semplificato. Un solo progetto, un solo team. La complessit&#xE0; dei progetti reali in realt&#xE0; pu&#xF2; essere molto diversa e costringerci ad affrontare i problemi dello sviluppo software con un occhio pragmatico e rivolto alla sostenibilit&#xE0; delle nostre scelte.
- Per&#xF2; il modello a cui facciamo riferimento &#xE8; oltremodo semplificato. Un solo progetto, un solo team. La complessit&#xE0; dei progetti reali in realt&#xE0; pu&#xF2; essere molto diversa e costringerci ad affrontare i problemi dello sviluppo software con un occhio pragmatico e rivolto alla sostenibilit&#xE0; delle nostre scelte.
- Per&#xF2; il modello a cui facciamo riferimento &#xE8; oltremodo semplificato. Un solo progetto, un solo team. La complessit&#xE0; dei progetti reali in realt&#xE0; pu&#xF2; essere molto diversa e costringerci ad affrontare i problemi dello sviluppo software con un occhio pragmatico e rivolto alla sostenibilit&#xE0; delle nostre scelte.
- Per&#xF2; il modello a cui facciamo riferimento &#xE8; oltremodo semplificato. Un solo progetto, un solo team. La complessit&#xE0; dei progetti reali in realt&#xE0; pu&#xF2; essere molto diversa e costringerci ad affrontare i problemi dello sviluppo software con un occhio pragmatico e rivolto alla sostenibilit&#xE0; delle nostre scelte.
- Per&#xF2; il modello a cui facciamo riferimento &#xE8; oltremodo semplificato. Un solo progetto, un solo team. La complessit&#xE0; dei progetti reali in realt&#xE0; pu&#xF2; essere molto diversa e costringerci ad affrontare i problemi dello sviluppo software con un occhio pragmatico e rivolto alla sostenibilit&#xE0; delle nostre scelte.
- Per&#xF2; il modello a cui facciamo riferimento &#xE8; oltremodo semplificato. Un solo progetto, un solo team. La complessit&#xE0; dei progetti reali in realt&#xE0; pu&#xF2; essere molto diversa e costringerci ad affrontare i problemi dello sviluppo software con un occhio pragmatico e rivolto alla sostenibilit&#xE0; delle nostre scelte.
- Per&#xF2; il modello a cui facciamo riferimento &#xE8; oltremodo semplificato. Un solo progetto, un solo team. La complessit&#xE0; dei progetti reali in realt&#xE0; pu&#xF2; essere molto diversa e costringerci ad affrontare i problemi dello sviluppo software con un occhio pragmatico e rivolto alla sostenibilit&#xE0; delle nostre scelte.
- Per&#xF2; il modello a cui facciamo riferimento &#xE8; oltremodo semplificato. Un solo progetto, un solo team. La complessit&#xE0; dei progetti reali in realt&#xE0; pu&#xF2; essere molto diversa e costringerci ad affrontare i problemi dello sviluppo software con un occhio pragmatico e rivolto alla sostenibilit&#xE0; delle nostre scelte.
- Per&#xF2; il modello a cui facciamo riferimento &#xE8; oltremodo semplificato. Un solo progetto, un solo team. La complessit&#xE0; dei progetti reali in realt&#xE0; pu&#xF2; essere molto diversa e costringerci ad affrontare i problemi dello sviluppo software con un occhio pragmatico e rivolto alla sostenibilit&#xE0; delle nostre scelte.
- L&#x2019;altro elemento di semplificazione irreale &#xE8; la presunzione di poter cominciare un progetto dal foglio bianco. Nel 2009 avremo sempre e comunque a che fare con applicazioni Legacy e con tutti i problemi che queste comportano.
- I nostri sogni di conquista incontrano un primo ostacolo. Non possiamo estendere il nostro approccio indefinitamente.
- Es: &#x201C;Papi&#x201D;&#x2026; :-)
- ... and the Romans were amongst then
- They were not originally meant to be part of the system
- In questo esempio un team &#xE8; cresciuto di dimensioni fino a dividersi in due. la comunicazione diventa meno efficace, ed in alcuni classi possono apparire classi simili che risolvono in maniera differente lo stesso problema.
- Soprattutto nella terra di nessuno tra pi&#xF9; contesti, quella dove &#xE8; difficile individuare un responsabile.
- Apparentemente un ovviet&#xE0;: in realt&#xE0; questa affermazione inizialmente era uno scherzo, ma studi scientifici pi&#xF9; approfonditi hanno dimostrato che era assolutamente vera, e che il fattore determinante era la distanza fra i team nell&#x2019;organigramma aziendale, pi&#xF9; che la vicinanza fisica.
- As ugly and dirty as it might look...
- &#xE8; comunque una mappa. Uno strumento per leggere il territorio, e piazzare le nostre truppe laddove possono essere pi&#xF9; efficaci contro il nemico. N.d.r. Questa &#xE8; la mappa della battaglia di Austerlitz, dove Napoleone ha vinto &#x2026; non si sa mai ...
- E&#x2019; necessaria una visione diversa, che ci permetta di non farci trascinare in battaglie che non possono essere vinte, con il rischio di ritrovarci frustrati perch&#xE9; nonostante le migliori intenzioni non siamo riusciti a portare a casa i risultati sperati.
- E&#x2019; necessaria una visione diversa, che ci permetta di non farci trascinare in battaglie che non possono essere vinte, con il rischio di ritrovarci frustrati perch&#xE9; nonostante le migliori intenzioni non siamo riusciti a portare a casa i risultati sperati.
- La scienza opera delle semplificazioni per spiegare i fenomeni, ma nella pratica spesso si deve fare i conti con il fatto che la semplificazione sia &#x2026; una semplificazione. Per anni si &#xE8; pensato al petrolio come ad una risorsa inesauribile, cos&#xEC; come all&#x2019;atmosfera. Ora facciamo i conti con un sistema geopolitico in cui consideriamo il petrolio come una fonte in potenziale esaurimento e dove i cambiamenti climatici ci costringono a ripensare molte delle nostre azioni, perch&#xE9; avevamo tralasciato di considerare le conseguenze...
- In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare. Gli sviluppatori sono spesso considerati &#x201C;carne da cannone&#x201D;: il numero e la provenienza non &#xE8; un problema.
- In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare. Gli sviluppatori sono spesso considerati &#x201C;carne da cannone&#x201D;: il numero e la provenienza non &#xE8; un problema.
- In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare. Gli sviluppatori sono spesso considerati &#x201C;carne da cannone&#x201D;: il numero e la provenienza non &#xE8; un problema.
- In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare. Gli sviluppatori sono spesso considerati &#x201C;carne da cannone&#x201D;: il numero e la provenienza non &#xE8; un problema.
- In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare. Gli sviluppatori sono spesso considerati &#x201C;carne da cannone&#x201D;: il numero e la provenienza non &#xE8; un problema.
- In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare. Gli sviluppatori sono spesso considerati &#x201C;carne da cannone&#x201D;: il numero e la provenienza non &#xE8; un problema.
- In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare. Gli sviluppatori sono spesso considerati &#x201C;carne da cannone&#x201D;: il numero e la provenienza non &#xE8; un problema.
- In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare. Gli sviluppatori sono spesso considerati &#x201C;carne da cannone&#x201D;: il numero e la provenienza non &#xE8; un problema.
- In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare. Gli sviluppatori sono spesso considerati &#x201C;carne da cannone&#x201D;: il numero e la provenienza non &#xE8; un problema.
- In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare. Gli sviluppatori sono spesso considerati &#x201C;carne da cannone&#x201D;: il numero e la provenienza non &#xE8; un problema.
- In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare. Gli sviluppatori sono spesso considerati &#x201C;carne da cannone&#x201D;: il numero e la provenienza non &#xE8; un problema.
- In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare. Gli sviluppatori sono spesso considerati &#x201C;carne da cannone&#x201D;: il numero e la provenienza non &#xE8; un problema.
- In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare. Gli sviluppatori sono spesso considerati &#x201C;carne da cannone&#x201D;: il numero e la provenienza non &#xE8; un problema.
- In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare. Gli sviluppatori sono spesso considerati &#x201C;carne da cannone&#x201D;: il numero e la provenienza non &#xE8; un problema.
- In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare. Gli sviluppatori sono spesso considerati &#x201C;carne da cannone&#x201D;: il numero e la provenienza non &#xE8; un problema.
- In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare. Gli sviluppatori sono spesso considerati &#x201C;carne da cannone&#x201D;: il numero e la provenienza non &#xE8; un problema.
- In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare. Gli sviluppatori sono spesso considerati &#x201C;carne da cannone&#x201D;: il numero e la provenienza non &#xE8; un problema.
- In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare. Gli sviluppatori sono spesso considerati &#x201C;carne da cannone&#x201D;: il numero e la provenienza non &#xE8; un problema.
- In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare. Gli sviluppatori sono spesso considerati &#x201C;carne da cannone&#x201D;: il numero e la provenienza non &#xE8; un problema.
- In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare. Gli sviluppatori sono spesso considerati &#x201C;carne da cannone&#x201D;: il numero e la provenienza non &#xE8; un problema.
- In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare. Gli sviluppatori sono spesso considerati &#x201C;carne da cannone&#x201D;: il numero e la provenienza non &#xE8; un problema.
- In un tipico progetto dobbiamo quindi fare i conti con delle risorse finite: tradizionalmente soldi e tempo sono le risorse classiche da considerare. Gli sviluppatori sono spesso considerati &#x201C;carne da cannone&#x201D;: il numero e la provenienza non &#xE8; un problema.
- la comunicazione, o meglio il tempo allocato per lo scambio di informazioni &#xE8; forse la grandezza meno considerata in sede di large scale project management. Ma la quantit&#xE0; di informazioni che pu&#xF2; essere scambiata in una grande organizzazione &#xE8; una grandezza finita.
- Nonostante le aziende continuino a trattarci come parte di una &#x201C;intelligenza collettiva&#x201D; non c&#x2019;&#xE8; alcuna speranza che le informazioni circolino solo perch&#xE8; sono state messe sul Wiki, o che tutti gli sviluppatori siano continuamente aggiornati via RSS Feed su tutto ci&#xF2; che avviene nel progetto.
- In realt&#xE0; nei progetti di grandi dimensioni &#xE8; facile la situazione opposta: la quantit&#xE0; di informazioni da sapere prima di poter scrivere una sola riga di codice &#xE8; (teoricamente) talmente elevata che, specialmente in caso di turnover, la maggior parte di queste viene bellamente ignorata. Nell&#x2019;immagine un soldato giapponese catturato dagli americani al termine della seconda guerra mondiale. Molti militari di stanza nel pacifico continuarono a combattere a lungo senza essere informati della fine delle ostilit&#xE0;.
- Mettersi d&#x2019;accordo &#xE8; una delle forme di comunicazioni pi&#xF9; sofisticate che esistano tra esseri umani: implica comprensione del problema da ambo le parti individuazione di possibili soluzioni raggiungimento di un compromesso soddisfacente ...non avviene per caso o per fortuna.
- La gestione a turnover selvaggio, di &#x201C;risorse intercambiabili&#x201D; complica ulteriormente il problema. &#xC8; molto semplicemente un incentivo all&#x2019;ignoranza.
- Le persone non sono tutte uguali, per le capacit&#xE0;, per il rendimento, la competenza etc etc etc. trattarle come intercambiabili significa avere il minimo rendimento da ciascuna di esse.
- In definitiva, fare la cosa giusta &#xE8; realmente la cosa pi&#xF9; difficile.
- Cosa rende speciale la nostra azienda (o l&#x2019;azienda nostra cliente)? Come possiamo massimizzare il valore prodotto?
- Come possiamo definire il successo della nostra applicazione? non &#xE8; morto nessuno? nessuno ci ha denunciato? abbiamo consegnato qualcosa? abbiamo consegnato in tempo? gli utenti hanno usato l&#x2019;applicazione? gli utenti hanno apprezzato l&#x2019;applicazione? l&#x2019;applicazione ha aumentato i profitti del nostro cliente? le persone sono pi&#xF9; felici perch&#xE9; esiste la nostra applicazione?
- Lavorare pensando solo alla riduzione dei costi porter&#xE0; a tagliare la qualit&#xE0; o a fare applicazioni &#x201C;come quell&#x2019;altra&#x201D;. Vogliamo applicazioni che apportino dei benefici.
- DDD richiede risorse &#x201C;speciali&#x201D; e quindi non pu&#xF2; essere applicato a tappeto. Dobbiamo capire dove questo possa apportare dei benefici. &#xC8; estremamente raro che la tecnologia in se per se possa rappresentare un vantaggio competitivo. Ancora pi&#xF9; raro che questo sia durevole.
- Noi abbiamo gi&#xE0; una mappa, e la conoscenza del terreno &#xE8; fondamentale per prendere le decisioni corrette.
- &#xC8; puro realismo. Un&#x2019;applicazione uniformemente ben progettata non esiste. E&#x2019; importante che sia ben progettata dove serve, ed abbastanza ben progettata nelle altre parti.
- Cos&#x2019;&#xE8; importante e cosa no non dipende da noi, ma dipende dallo scenario business. Solo interagendo con l&#x2019;area business possiamo pensare di fare la cosa giusta, al momento giusto.