Ddd brutto sporco e cattivo
•Descargar como KEY, PDF•
9 recomendaciones•2,184 vistas
La mia presentazione su Domain-Driven Design in ambiente legacy, ri-editata dopo il Codemotion di Roma.
Recomendados
Más contenido relacionado
Más de Alberto Brandolini
Más de Alberto Brandolini (20)
Ddd brutto sporco e cattivo
- 2. Obiettivo #1 Arrivare a DDD non partendo dal foglio bianco...
- 3. Obiettivo #2 Arrivare a DDD in maniera non prescrittiva
- 4. Do you really need me?
- 5. Checkpoint Quando fare DDD? - Problema complesso - Aspettative elevate
- 6. Anti-pattern Voglio fare DDD Non lo conosco molto bene... ...quindi lo applico ad un problema semplice Non ne vedo i vantaggi ...DDD non serve.
- 7. Sbagliato
- 8. Non si impara in pianura
- 11. Non è questo il nostro lavoro
- 12. C’è chi lo sa fare meglio
- 13. La rete di protezione ✓Ambienti ✓Build script ✓Test suite ✓Database privato ✓Fixtures
- 14. Strumenti
- 15. Professionisti
- 17. Anche nelle peggiori condizioni
- 19. Infermiera, mi passa Quello a punta? Sì, quello con la punta un po’
- 20. Strumenti
- 21. Precisione
- 22. Aspirina Anticoncezionale
- 23. Linguaggio
- 24. Siete
- 25. Checklist Strumenti? --> Strumento. (Sempre e solo quello) Precisione? --> “Quando sei in stato 12 il campo MRKT_NFLD può valere solo B o K” Linguaggio? --> :-( avanscoper ta
- 27. Qual è la differenza tra i maiali e le applicazioni?
- 28. Checklist data-based Siamo in grado di sapere... Quale applicazione è responsabile della struttura del dato? Quale requisito ne ha influenzato la definizione? E’ ancora valido? È valido nel mio contesto? Quali applicazioni utilizzano quel dato? Quali conseguenze avremo cambiandone la struttura? avanscoper ta
- 29. Obiettivo #1 Arrivare a DDD non partendo dal foglio bianco...
- 30. Soluzione #1 Mettere da parte il casino e cominciare dal foglio bianco...
- 31. Quale problema vogliamo risolvere?
- 32. Uno
- 33. Il nostro
- 34. Complessità Dominio del Nostro PROBLEMA SOLUZIONI precedenti 15% 85%
- 35. Il nostro problema Altro contesto Altro contesto I d at i d a c o n di v id Il nostro contesto ere I nos t r i d at i Il nostro database
- 36. THIS DATABASE IS MY DATABASE TRESPASSERS WILL BE SHOT SURVIVORS WILL BE SHOT AGAIN
- 37. Dev: “Detto così è semplice...”
- 39. DDD serve a risolvere problemi complessi,
- 40. DDD serve a risolvere problemi complessi, NON a complicare problemi semplici.
- 41. Strategie per gestire gli zombi
- 45. A Romolo!! E famme fà ‘sta
- 46. A Romolo!! E famme fà ‘sta None
- 47. A Romolo!! E famme fà ‘sta None Eddai ...è di sola lettura...
- 50. Bounded Context
- 51. Anti-Corruption Layer Our Context ACL da ry Other Context u ndar y ex t boun bo con t co n te x t <<Entity>> MyEntity Attributo Attributo <<Service>> Componente ContactService getContattiUnici(…):List<Contatto> ContactService <<Value Object>> Contatto Attributo Attributo
- 52. Anti-Corruption Layer Our Context ACL da ry Other Context u ndar y ex t boun bo con t co n te x t <<Entity>> MyEntity Attributo Attributo <<Service>> Componente ContactService getContattiUnici(…):List<Contatto> ContactService <<Value Object>> Contatto Attributo Attributo Il modello come dovrebbe essere
- 53. Anti-Corruption Layer Our Context ACL da ry Other Context u ndar y ex t boun bo con t co n te x t <<Entity>> MyEntity Attributo Attributo <<Service>> Componente ContactService getContattiUnici(…):List<Contatto> ContactService <<Value Object>> Contatto Attributo Attributo La componente Il modello come legacy, con i dovrebbe essere suoi guai
- 54. Anti-Corruption Layer Our Context ACL da ry Other Context u ndar y ex t boun bo con t co n te x t <<Entity>> MyEntity Attributo Attributo <<Service>> Componente ContactService getContattiUnici(…):List<Contatto> ContactService <<Value Object>> Contatto Attributo Attributo La Qui risolviamo il componente Il modello come casino, anche con legacy, con i dovrebbe essere le maniere forti suoi guai
- 55. ...e dentro il nostro Bounded Context...
- 57. Non è poi così importante...
- 58. Compliance
- 61. DDD patterns a supporto di riscritture frequenti
- 62. DDD come architettura di supporto all’evoluzione
- 63. meglio dotarci di adeguati strumenti di supporto alla progettazione
- 64. Lavagne
- 65. CRC Cards
- 66. P.O.: “Davvero possiamo fare questo?”
- 68. Dev: “Dobbiamo mettere uno strato di validazione per evitare che i dati sporchi entrino nel sistema”
- 69. Davvero?
- 71. La validazione complessa è uno smell
- 72. Dati (quasi) uguali <<Entity>> <<Entity>> FatturaPreview Fattura importo importo cliente cliente stato modifica emetti convalida registraPagamento Comportamento differente
- 73. Multiple models
- 75. 3 archetipi? Costruzione collaborativa Topic+Conversation Facebook, Basecamp, Github Esecuzione Macchina a stati, Commands Tracking Logging, Auditing, Datawarehouse, Eventi
- 76. E il DBA che dice?
- 77. DBA: “Mi aspettavo che fosse stata definita per bene la struttura del database, una volta per tutte”
- 78. ...
- 79. Prima idea...
- 81. Può una componente progettata prima di una applicazione essere adeguata alle N applicazioni successive?
- 82. Ostacoli
- 84. Per poter interagire con il sistema X devi guardarti le spalle
- 85. Ci sono delle f***ute stored procedure che girano ogni 10 minuti
- 86. Nessuno sa esattamente come funzionino
- 87. Nessuno le ha mai Nessuno sa cambiate ed è tornato vivo esattamente come per raccontarlo funzionino
- 89. Hrmpf
- 90. Rischio...
- 91. Mi raccomando, copriti quando Ti sei messo la Chiudi la canottiera? porta a chiave, quando esci!
- 92. Ansia
- 93. Carico cognitivo Quante cose devo sapere prima di toccare il codice?
- 94. Possiamo essere ignoranti e produttivi allo stesso tempo?
- 95. Transaction management? Presentation Layer Application Layer Domain Layer Infrastructure Layer pi em D DD es gli de % 99
- 96. Repository & SRP <<factory>> OrderFactory createEmpty() Application Layer creates Domain Layer <<Entity>> <<Facade>> Order Application Facade price createOrder(…) customer delivery(order_ID, …) delivery() Crea il contesto e lo passa al repository <<Repository>> opens / closes OrderRepository save(Order, Context) findById(id, Context) Riceve il contesto uses transazionale Il Repository effettua le dall'e sterno operazioni di aggiunta e/o <<ORM>> rimozione dal contesto, ma è Context l'application layer ad invocare +saveChanges() saveChanges() Infrastructure layer
- 98. ...mettiamo una tabella condivisa...
- 100. Ooops...
- 103. Motivazioni
- 104. Infanzia difficile
- 105. Infanzia difficile Persona nome cognome numeroTel Studente Professore numeroMatricola anzianità
- 106. Dimostrami di essere una Persona...
- 107. ...Stampati!
- 108. Infanzia difficile
- 109. Infanzia difficile Persona nome cognome numeroTel Studente Professore numeroMatricola anzianità
- 110. Non stanno insieme! ...e non è colpa dell’ORM
- 111. Ogni regola architetturale che comincia con “ogni” è sbagliata!
- 112. Conseguenze
- 113. Vedi, il mondo si divide in due categorie: chi è in un bounded context, e chi scava...
- 114. Tu ...scavi
- 115. Stime
- 120. Stime
- 122. Stime Evoluzioni “esplorative” Legacy “vaso di Pandora”
- 123. Ignorance based planning 100% 90% 80% B re a kt 70% h ro u g h Ignorance 60% 50% 40% Ignorance 30% 20% 10%
- 124. Gold plating?
- 125. Si, ma come faccio a sapere se sto facendo DDD?
- 126. Sto veramente facendo Prodotto migliore delle aspettative Non abbiamo paura di riscriverne dei pezzi Ci stiamo divertendo avanscoper ta
- 127. domande?
- 128. domande? Sul serio, potete farle...
- 129. DDD, CQRS and Event Sourcing Bologna 16-17 aprile 2012 http://avanscopertacqrstraining15042012.eventbrite.com/ Advanced CQRS Workshop Bologna 18-20 aprile 2012 http://avanscopertacqrsworkshop18042012.eventbrite.com/ avanscopert © Alberto Brandolini 2009
Notas del editor
- \n
- A fare DDD partendo dal foglio bianco, sono capaci tutti...\n(non &#xE8; proprio cos&#xEC;, in effetti).\nMa in questo caso la cosa che ci interessa di pi&#xF9;\n
- \n
- \n
- \n
- \n
- \n
- Abbiamo bisogno di un problema complesso. Altrimenti facciamo solo fatica.\nEd il punto di partenza &#xE8; il comportamento, non i dati. Altrimenti &#xE8; molto pi&#xF9; efficace costruire un CRUD con Rails, Grails e compagni.\n
- Altro punto chiave. La sicurezza.\n\n
- ... non possiamo essere creativi ed artificieri allo stesso tempo. Lavorare su applicazioni legacy a cuore aperto, con sistemi che ci si appoggiano sopra e conseguenze inimmaginabili nel caso qualcuno decida fare una modifica minuscola ...non ha molto a che fare con il nostro lavoro.\n
- \n
- Siamo sviluppatori, non artificieri.\nNon significa &#x201C;noi vogliamo fare solo la parte divertente del lavoro&#x201D; ma che i lavori sono due, e ben diversi l&#x2019;uno dall&#x2019;altro.\nE soprattutto che &#x201C;controllare che cambiando questa cosa non si sia rotto niente&#x201D; non &#xE8; un lavoro da sviluppatore. &#xC8; un lavoro da test automatizzato.\n
- Cerchiamo di essere pi&#xF9; espliciti? Davvero pensate di poter fare uno sviluppo ad elevato tasso evolutivo senza avere i fondamentali a posto? Il processo deve essere robusto, altrimenti ci si pu&#xF2; fare molto male. Vogliamo andare in produzione spesso: non &#xE8; un vezzo, &#xE8; necessario!\n
- Ok, parliamo dei nostri strumenti di lavoro.\n
- Abbiamo un compito difficile e delle responsabilit&#xE0;. Spesso dal fare le cose fatte bene dipende il core business della nostra azienda. Vogliamo fare un lavoro fatto bene e la scelta degli strumenti adatti (e la cura con cui li trattiamo) &#xE8; un elemento fondamentale per definire un professionista. Siamo professionisti?\n
- ...allora abbiamo diritto agli strumenti migliori disponibili :-)\n
- A parte gli scherzi, ci sono determinati fondamentali sui quali non si pu&#xF2; transigere, anche nelle peggiori condizioni. Anche in un ospedale da campo ci sono determinate regole.\n
- E quei (magari pochi) strumenti disponibili, sono tenuti in ordine.\n
- E tra colleghi NON ci si pu&#xF2; permettere un dialogo di questo genere. \n\n...ora ripensate all&#x2019;ultima volta in cui vi siete chiesti il significato di una variabile o di una colonna sul database, o che ve lo siete fatto spiegare dal vostro collega anziano, e probabilmente il significato e lo scopo di quella bizzarra idea dello Ubiquitous Language diventa un po&#x2019; pi&#xF9; chiara.\n
- Il linguaggio &#xE8; il nostro strumento principale, dobbiamo averne cura.\n
- E perch&#xE9; il linguaggio sia affilato ed efficace dobbiamo avere una cura maniacale per la precisione.\n
- Perch&#xE9; in assenza di precisione, &#xE8; facile confondersi e fare errori &#x201C;con conseguenze di lungo termine&#x201D;. \n\n...siete sicuri che il vostro database non sia strutturato in questo modo? Che ogni informazione sia in grado di descriversi da sola senza l&#x2019;apporto di un esperto in grado di dire perch&#xE9; &#xE8; cos&#xEC;? \n
- \n
- Siete sicuri che un artifact come un modello ER sia in grado di spiegare senza ambiguit&#xE0; alcuna il modello del vostro sistema?\n
- Io personalmente non credo.\nQuando abbiamo a che fare con un sistema legacy &#x201C;tipico&#x201D; spesso abbiamo a che fare con un modello che esclude il comportamento (il modello sono SOLO i dati ...e vedremo che c&#x2019;&#xE8; pi&#xF9; di un problema). Il linguaggio utilizzato non &#xE8; sufficientemente preciso, anzi &#xE8; un perfetto terreno di cultura per l&#x2019;ambiguit&#xE0;.\n
- Ripensando alle strategie classiche di integrazione (domanda: quali altre strategie di integrazione avete valutato, e scartato? ...e perch&#xE9;?) basate sui dati &#xE8; abbastanza evidente che non sia una strategia particolarmente sofisticata (sarcasmo) che pu&#xF2; essere conveniente solo in situazioni in cui non ci interessa pi&#xF9; di tanto gestire un&#x2019;evoluzione.\n\nStiamo condividendo un dato? Chi ne &#xE8; il resposnsabilie? Quali vincoli progettuali hanno fatto s&#xEC; che quel dato fosse\n
- A livello comportamentale spesso, poco. \nIn ogni caso il detto &#x201C;del maiale non si butta via niente&#x201D; ci fa capire che in un eventuale confronto il maiale vince a mani (zampe) basse, perch&#xE9; delle applicazioni cos&#xEC; fatte purtroppo dovremo buttare via un sacco di roba.\n
- \n
- Nel momento in cui ci troviamo per l&#x2019;ennesima volta a dover affrontare un problema apparentemente complesso, realizzando che la gran parte della complessit&#xE0; in realt&#xE0; &#xE8; estranea al nostro dominio appare chiaro che se ripercorriamo la stessa strada rischiamo di rifare gli errori gi&#xE0; commessi. E di ritrovarci esattamente nella stessa situazione.\n
- La strada pi&#xF9; interessante sembra essere quello della famosa barzelletta del matematico che si &#x201C;ricollega al caso precedente&#x201D;. Rimuoviamo dall&#x2019;analisi del problema tutto quello che non &#xE8; pertinente e cerchiamo la soluzione efficiente per il nostro problema. \n
- Realmente, dobbiamo partire sempre &#x201C;incartati&#x201D;?\n
- Dobbiamo risolvere UN problema, nel migliore dei modi possibili\n
- Il nostro problema &#xE8; quello importante. E su quello NON dobbiamo scendere a compromessi.\n
- ...soprattutto perch&#xE9; &#xE8; GIA&#x2019; un problema complesso per conto suo. Trovare una soluzione elegante ad un problema completamente sporcato dalle &#x201C;soluzioni&#x201D; precedenti non &#xE8; nemmeno detto che sia un problema risolvibile (anche se potrebbe fare contenti tanti cosiddetti &#x201C;architetti&#x201D;).\n
- Per cui deve essere estremamente chiaro che il nostro problema viene affrontato e risolto in un contesto ben definito e che non vogliamo avere niente a che fare con i problemi degli altri contesti.\nNoi abbiamo i nostri metodi.\n
- E non siamo disposti a scendere a compromessi. Callaghan ha una 44 magnum. La sua. Punto.\n
- La cosa pi&#xF9; interessante &#xE8; che questo commento &#xE8; stato presentato quasi con un senso di colpa... :-) quasi che isolare la radice del problema e mettere in evidenza che quel problema da solo non era poi cos&#xEC; complesso e poteva essere risolto in un tempo ragionevole fosse un&#x2019;atto di lesa maest&#xE0;...\n\nMa il nostro lavoro non &#xE8; creare complessit&#xE0;.\n
- \n
- \n
- Ok, bello ...ma come facciamo questa cosa in pratica, in un contesto in cui NON &#xE8; mai stata fatta?\n
- Beh la soluzione classica per proteggersi &#xE8; il recinto\n
- Ed a guardarci bene ...visto che siamo a Roma ... ci sono forti tradizioni al riguardo.\n
- sappiamo come &#xE8; andata a finire.\n
- sappiamo come &#xE8; andata a finire.\n
- sappiamo come &#xE8; andata a finire.\n
- E sappiamo anche che questa strategia ha funzionato. Questo &#xE8; il Vallo Adriano. I Barbari stanno da una parte, mentre dall&#x2019;altra siamo nell&#x2019;Impero Romano, dove valgono le leggi dell&#x2019;impero e la moneta dell&#x2019;impero.\n
- Specialmente in un campo minato, come le nostre belle suite di applicazioni legacy in cui tocchi una cosa e salta tutto, &#xE8; fondamentale sapere quando siamo in un terreno bonificato, in cui possiamo FINALMENTE sperimentare senza avere paura che esploda tutto, che l&#x2019;azienda fallisca o che l&#x2019;intero universo imploda su se stesso.\n
- Nella pratica, il pattern Domain-Driven Design che ci aiuta ad affrontare questo aspetto &#xE8; l&#x2019;Anti-Corruption Layer.\nAd esempio se la componente legacy aveva un problema di contatti duplicati - che a noi genera solo fastidio - l&#x2019;idea &#xE8; di sviluppare la componente nel nostro contesto come se questo problema non esista e quindi adoperarsi per risolverlo all&#x2019;interno dell&#x2019;ACL, il pi&#xF9; delle volte in un service.\n
- Nella pratica, il pattern Domain-Driven Design che ci aiuta ad affrontare questo aspetto &#xE8; l&#x2019;Anti-Corruption Layer.\nAd esempio se la componente legacy aveva un problema di contatti duplicati - che a noi genera solo fastidio - l&#x2019;idea &#xE8; di sviluppare la componente nel nostro contesto come se questo problema non esista e quindi adoperarsi per risolverlo all&#x2019;interno dell&#x2019;ACL, il pi&#xF9; delle volte in un service.\n
- Nella pratica, il pattern Domain-Driven Design che ci aiuta ad affrontare questo aspetto &#xE8; l&#x2019;Anti-Corruption Layer.\nAd esempio se la componente legacy aveva un problema di contatti duplicati - che a noi genera solo fastidio - l&#x2019;idea &#xE8; di sviluppare la componente nel nostro contesto come se questo problema non esista e quindi adoperarsi per risolverlo all&#x2019;interno dell&#x2019;ACL, il pi&#xF9; delle volte in un service.\n
- Ottimo, abbiamo fatto pulizia. Abbiamo creato finalmente un ambiente sano in cui occuparci del nostro problema.\n
- Ed a questo punto il giovane adepto di Domain-Driven Design non vede l&#x2019;ora finalmente di applicare tutti i pattern che ha visto nel libro di Eric Evans, con la segreta speranza di riuscire finalmente a capire che volesse dire...\n
- ma la cruda verit&#xE0; &#xE8; che applicare i pattern di Evans non &#xE8; poi cos&#xEC; importante.\n
- Nessuno vi dar&#xE0; un patentino di conformit&#xE0; ai principi DDD e sicuramente non &#xE8; quello il mio lavoro.\n
- E s&#xEC;, non c&#x2019;&#xE8; nessuna medaglia se siete stati bravi.\n
- E se avete tempo, date un&#x2019;occchiata a questo video sui paradigmi dell&#x2019;educazione e dell&#x2019;apprendimento. E se non avete tempo, trovatelo, perch&#xE9; ne vale la pena.\n\nDicevo, forse cercare la conformit&#xE0; ad un set di regole non &#xE8; proprio la strategia migliore per imparare la complessit&#xE0; di un nuovo dominio. Forse la strategia migliore &#xE8; provare a fare qualcosa di buono, ed a chiederci cosa ha funzionato e cosa no.\n
- Provo ad essere pi&#xF9; esplicito: nel 2004 quando &#xE8; uscito il libro, Eric ha fondamentalmente individuato un sottoinsieme di pattern che fossero a supporto di frequenti riscritture evolutive del codice. Non &#xE8; che &#x201C;ci deve essere un Factory&#x201D;, &#xE8; che siccome stiamo esplorando un dominio che non conosciamo, ci aspettiamo di riscrivere le classi fondamentali N volte. E per limitare i costi di evoluzione un Factory capita a fagiolo.\n\nAllo stesso modo, se NON evolviamo il codice, ma lo scriviamo e basta allora avremo la percezione che DDD &#xE8; inefficiente, rispetto ad altri approcci. Ma ...non stiamo facendo DDD.\n
- L&#x2019;obiettivo &#xE8; l&#x2019;evoluzione. I pattern sono (erano?) il miglior strumento conosciuto. Ma l&#x2019;obiettivo resta scrivere software che &#xE8; facile evolvere.\n
- A questo punto &#xE8; pi&#xF9; efficiente lavorare sugli strumenti di confronto e di condivisione delle idee. Guarda caso un aspetto su cui il nostro posto di lavoro potrebbe non essere proprio il migliore.\n
- Abbiamo strumenti per la discussione? Sono accessibili? La discussione &#xE8; sana?\n
- Impersonare le classi, capire i loro legami, in pi&#xF9; di un&#x2019;occasione ha portato a sbloccare questioni di modellazione apparentemente intricate. Cosa aspettate a provarci?\n\n...unico problema: le index card fatte cos&#xEC; sono quasi introvabili in Italia...\n
- E discutendo si arriva a quegli splendidi momenti in cui il backlog non &#xE8; pi&#xF9; la cesta della roba sporca. Ma le features scaturiscono dalle discussioni con i responsabili del progetto, che scoprono che ci sono possibilit&#xE0; a cui non avevano pensato o che non avevano osato chiedere. \n
- Ed improvvisamente si riesce ad intravvedere la luce. C&#x2019;&#xE8; vita oltre il legacy!\n
- Questo aspetto &#xE8; troppo ricorrente per non parlarne: nasce da una conversazione buttata l&#xE0;. Uno sviluppatore (legittimamente) preoccupato dei danni che una certa struttura dati avrebbe potuto provocare ha cercato di erigere una barriera, ...probabilmente mal consigliato dal sottoscritto :-)\n
- Solo che la mia risposta &#xE8; stata proprio l&#x2019;opposto.\n
- Perch&#xE9; se da un lato vogliamo evitare che i nostri dati vengano sporcati dalle applicazioni esterne, come abbiamo visto prima, dall&#x2019;altro ci sono un bel po&#x2019; di situazioni in cui bloccare l&#x2019;accesso delle situazioni non completamente conformi pu&#xF2; creare problemi ancora pi&#xF9; grossi. Non voglio qui aprire la questiona clandestinit&#xE0; ma ...ci siamo capiti ;-)\n
- Il punto &#xE8; che praticamente tutti i casi in cui c&#x2019;era da gestire una validazione complessa, il problema era un&#x2019;altro.\n
- E che quasi sempre la soluzione era data dal fatto che nel sistema esistessero due oggetti con una struttura dati quasi identica, ma con un comportamento completamente differente. Uno poteva essere incompleto, l&#x2019;altro doveva esserlo.\nState modellando queste due classi con lo stesso oggetto? In bocca al lupo!!!\n
- Perch&#xE9; nella nostra applicazione non c&#x2019;&#xE8; un solo modello, ma ci sono pi&#xF9; modelli ciascuno adatto a risolvere un particolare problema. Se avete chiaro quali sono i problemi che la vostra applicazione deve risolvere, diventa abbastanza chiaro anche che i modello sono diversi. ...e no, non &#xE8; detto che si debba sempre per forza trovare una soluzione di compromesso.\n
- \n
- Anche questo aspetto sta diventando troppo frequente per essere una coincidenza. Molte delle applicazioni che ho contribuito a progettare/realizzare hanno evidenziato la necessit&#xE0; di stili di programmazione differenti e di modelli tagliati a supportare differenti modalit&#xE0; di lavoro.\nCostruzione collaborativa di un artifact condiviso, durante la costruzione l&#x2019;artifact non &#xE8; sempre in uno stato consistente. La conversazione che avviene intorno ad aspetti selezionati dell&#x2019;artifact &#xE8; forse l&#x2019;aspetto pi&#xF9; interessante.\nEsecuzione che avvenga dentro l&#x2019;applicazione o attraverso l&#x2019;interazione con il cliente, il paradigma &#xE8; pi&#xF9; simile a quello di una macchina a stati, con una maggiore attenzione all&#x2019;integrit&#xE0; delle componenti.\nTracking beh, qui si tratta essenzialmente di monitoraggio. Dal banale logging alla generazione di warning personalizzati.\n
- Qui si aprirebbe tutto un&#x2019;altro capitolo... chi ha visto http://www.slideshare.net/ziobrando/drive-your-dba-crazy-in-3-easy-steps sa che ho un conto in sospeso con il DBA, che per una serie di motivi (ruolo, mentalit&#xE0;, posizione nell&#x2019;organizzazione, abitudini, status etc.) &#xE8; uno dei maggiori ostacoli all&#x2019;evoluzione del software in senso DDD.\n
- Nel nostro caso specifico la frase che pi&#xF9; mi ha scioccato &#xE8; stata questa.\n
- \n
- La prima idea &#xE8; abbastanza reattiva. Ma probabilmente non molto saggia.\n
- Quello che abbiamo fatto invece &#xE8; cercare di fare capire che la fata dai capelli turchini non esiste, e che &#xE8; necessario un processo di rilascio iterativo (quindi non solo incrementale) per le applicazioni. Ovviamente questo sulla base di collaborazione, venendo incontro a tutte le eventuali esigenze (sensate) in termini di policy, naming convention, etc...\n
- Ma non dimenticando la domanda di fondo, che di fatto mette in luce il peccato originale della programmazione data-driven in ambiente enterprise. Le scelte fatte nel momento di massima ignoranza sono le pi&#xF9; difficili da cambiare. \n
- Il DBA non &#xE8; l&#x2019;unico ostacolo sulla nostra strada.\n
- Se proviamo a chiedere ai nostri informatori come comportarci con i sistemi preesistenti, otteniamo risposte non necessariamente soddisfacenti.\n
- Si tratta di saggezza popolare tramandata oralmente a seguito di un rito di iniziazione, probabilmente.\n
- E ci sono dei tab&#xF9;. Cose che non si possono fare anche se si &#xE8; persa la nozione del perch&#xE9;.\n
- Non esattamente soddisfacente.\n
- La cosa forse pi&#xF9; angosciante &#xE8; che spesso la descrizione di un sistema legacy si focalizza sulle cose a cui devi stare attento.\n
- Purtroppo la sensazione quando affrontiamo questo tipo di sviluppo mi porta molto a pensare a questo tipo di consigli.\n
- Ed alla sensazione di ansia e di oppressione che mi mettevano addosso.\n
- Il buon vecchio Uncle Bob mette in evidenza questo aspetto, parlando di Carico Cognitivo. Nel campo della User Experience se ne parla per rendere pi&#xF9; semplice l&#x2019;interfaccia utente della nostra applicazione.\nLa nostra interfaccia utente come sviluppatori &#xE8; il codice, ed il nostro obiettivo la sua evoluzione. Cos&#x2019;altro dovremmo sapere oltre quello che c&#x2019;&#xE8; nel codice?\n
- \n
- Tra i pochi aspetti tecnici di DDD che &#xE8; imprescindibile tenere in considerazione c&#x2019;&#xE8; quello della gestione delle transazioni. In questo caso il problema &#xE8; che a parte qualche caso virtuoso (es. le architetture basate su Spring) la stragrande maggioranza degli esempi sulla gestione delle transazioni ci manda nella direzione sbagliata.\n
- Non &#xE8; compito del repository (ne ha gi&#xE0; un altro) gestire il contesto transazionale. Spesso la soluzione pi&#xF9; pulita &#xE8; quella di implementare la UnitOfWork o esplicitare il contesto transazionale.\n
- Altro problema (o riproposizione di quello precedente) mentre stiamo sviluppando, arriver&#xE0; sempre qualcuno che &#x201C;deve integrarsi&#x201D; con la nostra applicazione.\nNon fidatevi.\n
- \n
- \n
- &#xE8; la volta che va tutto gi&#xF9;. Non si era detto che i confini vanno presidiati?\n\n
- Quindi l&#x2019;applicazione reale &#xE8; un po&#x2019; pi&#xF9; restrittiva.\n
- Se si tratta di un&#x2019;applicazione esterna ...in genere siamo pi&#xF9; propensi ad essere sospettosi. Con le applicazioni interne il problema &#xE8; simile, solo che tendiamo a fidarci.\n\nSbagliato.\n
- Ok ora Callaghan non &#xE8; che si chiede il perch&#xE9; pi&#xF9; di tanto.\n
- Per&#xF2; in effetti dobbiamo ammettere di avere avuto un infanzia difficile. Quanti di voi hanno portato un&#x2019;applicazione in produzione ed hanno tratto vantaggio da una modellazione di questo genere? Perch&#xE9; &#xE8; per fare queste cose che serviva la programmazione ad oggetti ...o no?\n
- Alla fine OOP &#xE8; la superclasse persona che serve a ...\n
- stampare!!! (perepeppep&#xE8;!!!) \nNo veramente, non pu&#xF2; essere cos&#xEC;.\n
- Il punto &#xE8; che gi&#xE0; la OOP applicata male &#xE8; un problema. Ci aggiungiamo il fatto che il data-model &#xE8; al 99% dei casi sbagliati, mettete insieme le due cose e ...\n
- No, sul serio, non &#xE8; un problema dell&#x2019;ORM. Il poverino.\n
- &#xE8; pi&#xF9; probabilmente la conseguenza dell&#x2019;applicazione a tappeto di un solo problema, senza che nessuno che ci abbia spiegato i limiti di applicazione, tanto di OOP che del resto.\n
- ...o lessons learned.\n
- L&#x2019;aspetto pi&#xF9; evidente &#xE8; forse la diversit&#xE0; di approccio che possiamo avere una volta che abbiamo definito correttamente i confini del nostro Bounded Context.\n
- Difficile accettare di tornare indietro: perch&#xE9; la percezione del valore che possiamo apportare alla realizzazione &#xE8; tale che diventa difficile accettare di tornare a lavorare in situazioni ad alto rischio e basso valore aggiunto. \n
- Questo &#xE8; un aspetto chiave, che in pi&#xF9; di un&#x2019;occasione &#xE8; stato segnalato. Il punto &#xE8; che gi&#xE0; di per se &#xE8; difficile stimare un progetto greenfield (perch&#xE9; ad un certo punto si inizia ad andare molto pi&#xF9; forte ma &#xE8; difficile capire quando) ma le cose si complicano ulteriormente quando dobbiamo stimare DDD messo in mezzo o sopra al legacy. Perch&#xE9; dobbiamo fare 2 lavori. \n
- Facciamo l&#x2019;esempio del piastrellista. Se gli date la metratura della casa e qualche altro parametro, un preventivo accurato &#xE8; in grado di farvelo.\n
- Se per&#xF2; gli fate trovare le stanze in questo stato... i casi sono due. O se ne va e (forse) torna quando la stanza &#xE8; a posto. Oppure si rimbocca le maniche e vi fa pagare il lavoro extra ... che NON &#xE8; il lavoro da piastrellista.\n
- Se poi il lavoro &#xE8; questo? Ok ...questa bomba ha un timer. Ma provate a chiedere &#x201C;quanto tempo ci vuole per disinnescarla&#x201D;?\n\nOppure: &#x201C;quanto vuoi essere pagato per disinnescarla?&#x201D; \n
- E soprattutto non dimentichiamo che &#x201C;metterci in condizioni di sicurezza&#x201D; ha un costo.\nE non dimentichiamo nemmeno che questo costo si sarebbe gi&#xE0; dovuto pagare prima.\nNon &#xE8; un costo imputabile al vigile se non vi mettete le cinture.\n
- Per cui di fatto abbiamo 2 componenti nelle stime che &#xE8; bene tenere separate: una parte mediamente variabile legata ad un percorso di evoluzione esplorativa, che va stimata lasciando margine per fare errori ed esplorazioni, che per&#xF2; servono per abilitare le evoluzioni da &#x201C;performance boost&#x201D;. Un&#x2019;altra parte &#xE8; invece legato al legacy, al campo minato ed al tempo necessario per mettere in sicurezza i punti di confine e questo dipende sostanzialmente dalla qualit&#xE0; del codice pre-esistente.\n
- Per cui di fatto abbiamo 2 componenti nelle stime che &#xE8; bene tenere separate: una parte mediamente variabile legata ad un percorso di evoluzione esplorativa, che va stimata lasciando margine per fare errori ed esplorazioni, che per&#xF2; servono per abilitare le evoluzioni da &#x201C;performance boost&#x201D;. Un&#x2019;altra parte &#xE8; invece legato al legacy, al campo minato ed al tempo necessario per mettere in sicurezza i punti di confine e questo dipende sostanzialmente dalla qualit&#xE0; del codice pre-esistente.\n
- Il lato positivo &#xE8; dato dal fatto che se possiamo fare esplorazioni ...&#xE8; probabile che si trovi qualcosa di molto interessante. E andando aggressivamente a cercare le aree che ci sono meno chiare, possiamo anticipare questo momento della verit&#xE0;.\n&#xC8; garantito? No. &#xC8; molto probabile. Quello che &#xE8; garantito &#xE8; che questo cambio di passo non succeder&#xE0; in un progetto sotto strettissima pianificazione. \n
- Abbiamo questo rischio? Che la tanto agognata possibilit&#xE0; di fare le cose per bene ci porti ad un eccessivo amore per le riscritture, anche quelle che non portano valore? S&#xEC;, &#xE8; possibile. Ma si contrasta con la strategia di planning vista prima. Cambiamo le cose alla luce delle cose nuove che abbiamo imparato, non di un gusto estetico pi&#xF9; sofisticato. \n
- La domanda finale...\n
- \n
- \n
- \n
- \n