Stai guardando i dati sbagliati
Oct. 3, 2012•0 likes•3,477 views
Download to read offline
Report
Technology
Better Software 2012 - Questo è il mio talk sull'architettura software. Si parla di DDD, Event Sourcing, Bounded Contexts, SOA, maiali e simili.
Alberto BrandoliniFollow
More Related Content
Viewers also liked
C# e la Framework Class LibraryManuel Scapolan
JavaScript Object OrientedManuel Scapolan
AntiPatterns: i vizi del programmatoreManuel Scapolan
JavaScriptManuel Scapolan
TFS and Scrum - Lessons LearnedManuel Scapolan
Knockout.jsManuel Scapolan
Similar to Stai guardando i dati sbagliati
Webinar: "Conosci la Performance Intelligence?" a cura d A. SzambelanMiriade Spa
Blomming Lean Startup @ Better Software 2011Nicola Junior Vitto
Un plug-in Eclipse per il supporto all'Extract Class RefactoringFabio Palomba
Software ...e tutto ciò che comportaAlberto Brandolini
Software Testing Forum 2012 - Polarion e TRS SpAEmerasoft, solutions to collaborate
Generazione Automatica Di Codice Orientato Agli Oggetti TramiteMarco Montanari
More from Alberto Brandolini
L'illusione dell'ortogonalitàAlberto Brandolini
Redesigning everything ITARC Stockholm 2021Alberto Brandolini
What lies beneathAlberto Brandolini
Redesigning everything (avanscoperta meeutp edition)Alberto Brandolini
Extreme DDD modellingAlberto Brandolini
The gordian knotAlberto Brandolini
Stai guardando i dati sbagliati
- 1. Stai guardando i dati sbagliati @ziobrando
- 2. About me In the IT field since ZX Spectrum Generally in large scale projects (I might be biased) Strategic IT Consultant Trainer (Avanscoperta & Skills Matter) Technical Writer Blogger: http://ziobrando.blogspot.com Twitter: @ziobrando My e-mail: alberto.brandolini@gmail.com
- 3. What I do Agile processes Domain-Driven Design Efficiency & Management Architecture Funny clown 9% 11% 38% 12% 31%
- 4. Preludio
- 6. Il problema (o quella strana situazione che riteniamo essere il problema)
- 7. Architettura
- 8. Risultati incredibil i
- 9. Finché...
- 11. JENGA!
- 12. Perché?
- 13. L’architettura più comune?
- 14. Data-based Application Application Application http://martinfowler.com/bliki/ IntegrationDatabase.html
- 15. on at ion ica ti on ti on Applic Ap pl li ca ti pli ca ti on pp Ap li ca Ap A pp ati on pl A pplic ic at A io n Database a ti on pplic Databas A e Data-based integration
- 16. Poi, su questa architettura... qualche problema è emerso.
- 17. Eccessivo accoppiamento
- 19. Allungamento tempi di sviluppo
- 20. Allungamento tempi di sviluppo Affidabilità in calo
- 21. Allungamento tempi di sviluppo Affidabilità in calo Bug a sorpresa
- 22. Allungamento tempi di sviluppo Affidabilità in calo Bug a sorpresa Riunioni, riunioni,
- 23. Allungamento tempi di sviluppo Affidabilità in calo Bug a sorpresa Riunioni, riunioni, Notti
- 24. Allungamento tempi di sviluppo Affidabilità in calo Bug a sorpresa Riunioni, riunioni, Notti Addio ferie
- 26. Potremmo applicare SOA!!!
- 27. SOA? Application Application Application Service Layer
- 28. ...e questo? Application Application Application Service Layer
- 29. Magari più avanti
- 30. SOA :-/ Application Application Application Service Layer
- 31. Insegnare ai maiali a mangiare con le posate!
- 32. Magazzino... ID_Articolo Giacenza 1234 0
- 33. Magazzino... ID_Articolo Giacenza Consegna Fornitore(100) 1234 100 UPDATE Giacenza SET Giacenza=100 WHERE ID_articolo=1234
- 34. Magazzino... ID_Articolo Giacenza Spedizione a cliente(50) 1234 50 UPDATE Giacenza SET Giacenza=50 WHERE ID_articolo=1234
- 35. Magazzino... ID_Articolo Giacenza Danneggiamento(12) 1234 38 UPDATE Giacenza SET Giacenza=38 WHERE ID_articolo=1234
- 36. Magazzino... ID_Articolo Giacenza Smarrimento(2) 1234 36 UPDATE Giacenza SET Giacenza=36 WHERE ID_articolo=1234
- 37. Magazzino... ID_Articolo Giacenza Ritrovamento(1) 1234 37 UPDATE Giacenza SET Giacenza=37 WHERE ID_articolo=1234
- 38. Magazzino... ID_Articolo Giacenza Reso(5) 1234 ?
- 39. Magazzino... ID_Articolo Giacenza Controllo 1234 32 Disponibilità(32) UPDATE Giacenza SET Giacenza=32 WHERE ID_articolo=1234
- 40. Che fine hanno fatto? • Consegna Fornitore (100) • Spedizione al cliente(50) • Danneggiamento(12) • Smarrimento(2) • Ritrovamento(1) • Reso(5) • Controllo Disponibilità(32)
- 41. Requirements
- 42. RequirementsND A
- 43. RequirementsND A Vogliamo sapere in ogni istante quale utente ha compiuto quale operazione
- 44. RequirementsND A Vogliamo sapere in ogni istante quale utente ha compiuto quale operazione Tutte le operazioni di accesso e modifica del dato da parte delle applicazioni devono essere tracciate
- 46. Logging
- 47. Application Application Application Service Layer
- 51. C’è sempre chi scavalca
- 52. We Data
- 53. I dati sono il cuore del nostro sistema Abbiamo un problema di dati sporchi
- 54. I dati sono il cuore del nostro sistema Abbiamo un problema di dati sporchi
- 55. oops
- 56. We Data
- 57. What about ?
- 58. Come si arriva fin qua?
- 59. Con le migliori intenzioni
- 60. Da una base semplice
- 61. Come si fanno le cose grandi?
- 62. Come le piccole, solo ...più grandi!
- 63. Si imita...
- 64. Ci si documenta...
- 66. Sviluppi lenti Bug Notti insonni Procedure Complessità Rework Sprechi Turnover
- 67. Possibile che non ci sia un altro modo?
- 68. Mossa N°1 - Aggregates Le cose che cambiano insieme stanno
- 69. Aggregate boundaries? Ordine mod_spedizione VoceOrdine Articolo importo Quantità Descrizione prezzo destinatario Cliente indirizzo
- 70. Cambiano per motivi diversi Ordine mod_spedizione VoceOrdine Articolo importo Quantità Descrizione prezzo prezzo descrizione Destinatario indirizzo Cliente indirizzo
- 71. Gli aggregati sono parte del modello
- 72. ...e smettiamo di dare la colpa all’ORM!
- 74. Quali attributi sono necessari per il comportamento?
- 75. Notifica al resto del sistema mediante Domain Events
- 76. Mossa N°2 - Event Sourcing La verità è nel flusso degli eventi
- 77. The paper based system
- 78. Lo stato del sistema è il risultato della sequenza degli eventi che lo hanno interessato
- 79. Cart.CreateEmpty() .apply(ItemAdded(...)) .apply(ItemAdded(...)) .apply(ItemAdded(...)) => Il carrello è attivo
- 80. Non c’è perdita di informazione
- 81. Mossa N°3 - CQRS Command/Query Responsibility
- 82. No compromessi
- 83. Command ! Indirizzati ad entità singole il comportamento è importante la Flessibilità è importante © Alberto Brandolini - 2010
- 84. Query Grosse quantità di dati ? Non c’è comportamento le Prestazioni sono importanti Disponibili numerosi componenti off-the shelf © Alberto Brandolini - 2010
- 85. ! Architettura ottimizzata per i comandi ? Architettura ottimizzata per le letture
- 86. Domain Model Command Aggregate Event Event store Event Event Event UI Event Command Aggregate Event Event Presentatio UI n Event UI Projection DTO Projection UI DTO Read Model
- 87. Come non fare la dichiarazione dei redditi
- 89. Cara... Ti ricordi dove ho messo i documenti sanitari?
- 90. Come fare la dichiarazione dei redditi
- 92. Tell don’t Ask
- 93. o ...tradotto in romagnolo
- 94. Me a ni vò savê gnît
- 95. Computer Ottimo nelle operazioni ripetitive. Si ricorda di fare le cose Notifica con facilità
- 96. Mossa N°4 - Bounded Contexts Definiamo i reali confini delle componenti
- 97. Più modelli Product Delivery Publishing development Sales Marketing Customer Care Payments
- 98. Bounded Context • Linguaggio consistente all’interno • Un obiettivo ben preciso •Interlocutori ben definiti •Modelli indipendenti •Possibilità di scelte strategiche indipendenti
- 99. Eventi e Contesti Item delivered Item Order Product Available Received Designed Product for Product for Sales Delivery Ready Publishing Cart Created development Sales Item Order Availability Product Tested Visual Content Published Sales Fulfilled Ubdated approved Item Added to Marketing Text Content Cart Customer Care approved Issue Payment Issue Solved Sales price Initiated Payment Opened defined Accepted Payment Type Payments Selected Payment Refused
- 100. Accesso esclusivo L’appetito vien mangiando
- 101. Me a voj esr padrò’ in tla mi ca’
- 102. Possibili più rappresentazioni dello stesso concetto
- 104. Offerta != Contratto
- 105. Offerta != Contratto Bozza != Contratto
- 106. Offerta != Contratto Bozza != Contratto Carrello != Ordine
- 107. Offerta != Contratto Bozza != Contratto Carrello != Ordine Ordine != Ordine
- 108. Offerta != Contratto Bozza != Contratto Carrello != Ordine Ordine != Ordine Sorgente != eseguibile
- 109. No compromessi
- 110. Requisiti in conflitto?
- 111. Prestazioni?
- 112. No conflitti lock append only NoSQL eventual consistency data push model table per view Event no queries Stores Scalabilità su read
- 114. ma...
- 115. Non solo velocità
- 116. Non dobbiamo fare gli stessi errori più in fretta
- 117. Stakeholders
- 118. Sicurezza?
- 119. Requirements
- 120. RequirementsND A
- 121. RequirementsND A L’utente X non deve poter accedere all’informazione A
- 122. RequirementsND A L’utente X non deve poter accedere all’informazione A I campi della tabella K devono essere filtrati perché gli utenti Y e Z non possano vederli.
- 123. RequirementsND A L’utente X non deve poter accedere all’informazione A I campi della tabella K devono essere filtrati perché gli utenti Y e Z non possano vederli. L’informazione N deve essere di sola lettura per l’utente W
- 124. Interessante...
- 126. Mettiamo il badge ai maiali!
- 127. Testo rity ec u a ls S d en ti cre
- 128. Bounded Context? Product Delivery Publishing development Sales Marketing Customer Care Payments
- 129. Cose di cui parlo Cose a cui devo avere accesso
- 134. Il sistema è append-only
- 135. Non posso inserire dati “a manazza”
- 136. Non è tutto qui...
- 137. Event view Item delivered Item Order Product Available Received Designed for Sales Product Ready for Cart Sales Created Item Order Availability Product Visual Published Fulfilled Ubdated Tested Content approved Item Added to Text Cart Content approved Issue Payment Issue Solved Sales price Initiated Payment Opened defined Accepted Payment Type Selected Payment Refused
- 138. ...e sulle relazioni Item delivered Item Order Product Available Received Designed for Sales Product Ready for Cart Sales Created Item Order Availability Product Visual Published Fulfilled Ubdated Tested Content approved Item Added to Text Cart Content approved Issue Payment Issue Solved Sales price Initiated Payment Opened defined Accepted Payment Type Selected Payment Refused
- 139. Requisiti al bacio Quando il cliente effettua un ordine deve essere spedita un’e-mail di conferma Dato un cliente registrato X Quando X effettua un ordine Allora il sistema dovrebbe spedire un e- mail
- 140. Value flow Product Delivery Publishing development Sales Marketing Customer Care Payments
- 141. Sicuri che sia chiaro a tutti?
- 142. gli esperti ci e noi aiutano a capire aiutiamo loro © Alberto Brandolini 2009
- 143. Flussi di lavoro Item delivered Item Order Product Available Received Designed Product for Product for Sales Delivery Ready Publishing Cart Created development Sales Item Order Availability Product Tested Visual Content Published Sales Fulfilled Ubdated approved Item Added to Marketing Text Content Cart Customer Care approved Issue Payment Issue Solved Sales price Initiated Payment Opened defined Accepted Design Test Ready Payment Type Payments Selected Payment To do Doing Ready New Working Resolved Refused
- 144. See the whole?
- 145. Kanban Board = Bottleneck Detector
- 146. Ecosistema
- 147. Riunioni? Bug? Conflitti? Esperimenti?
- 148. Riunioni? Bug? Conflitti? Esperimenti? Valore?
- 149. Conclusioni
- 150. Ogni mossa porta valore
- 151. Devo farle tutte? No, ma...
- 152. Implementazioni parziali
- 153. Ottimizzazione percorsi di crescita
- 154. Strumenti... geteventstore.co
- 155. Rimboccars i le maniche!
- 157. Ripresa?
- 158. Domande?
- 159. Grazie! @ziobrando alberto.brandolini@avanscoperta.it
- 160. Implementing Domain-Driven Design Vaughn Vernon http://www.amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/ 0321834577 Event Centric Greg Young http://www.amazon.com/Event-Centric-Simplicity-Addison-Wesley-Signature/dp/0321768221 Per saperne di più... www.avanscoperta.it
- 161. Domain-Driven Design Eric Evans Enterprise Integration Patterns Gregor Hohpe, Bobby Woolf Patterns of Enterprise Application Architecture Martin Fowler Per saperne di più... www.avanscoperta.it
Editor's Notes
- \n
- \n
- \n
- \n
- Qualche collega mi ha raccontato questa storia. Assumo non sia una barzelletta.\n\nA causa di un furto, il collega si reca in caserma per una denuncia. Il militare scrive la denuncia al computer, stampa, fa firmare e ...cancella il file! Il collega, basito, chiede: “ma perché lo ha cancellato?” ... “tanto non serviva più!”\n
- Ok, proviamo a raccontare il punto di partenza, anche se lo conosciamo benissimo.\n
- Parliamo di architettura. \nO meglio, di architettura software.\nO meglio, di quella che ci hanno fatto credere sia un’architettura software.\n\n
- Che è tutto sommato questa. Il Jenga.\nUn’architettura che con un sacco di pratica permette di ottenere dei risultati incredibili, tipo due applicazioni che si parlano, senza che il server cada troppo spesso.\n
- Solo che ogni tanto... va giù. Aggiungendo una feature, un requisito, una componente esterna. Ad un certo punto collassa.\n
- E tutti gridano insieme “JENGA!” ed in tutta l’azienda si celebra una grande festa, e tutti sono felici.\n\n\n... o no?\n
- Perché succede tutto questo?\n
- Qual è realmente l’architettura più comune. Quella più diffusa nei dipartimenti IT italiani?\n
- È quella che Martin Fowler in “Patterns of Enterprise Application Architecture” chiama Data-Based integration.\n\nMa il fatto che sia sul libro di Fowler, non dovrebbe significare granché. I libri di pattern servono a catalogare la realtà in maniera agnostica. Senza troppi giudizi o orientamenti ideologici.\n\nIo non sono Fowler e sono molto orientato ideologicamente, e quindi posso utilizzare una notazione un po’ più espressiva.\n
- Questa rende decisamente meglio l’idea. \nMa i maiali mangiano di tutto, quindi per un po’ questa situazione ci è sembrata un’ottima idea.\n
- Ma solo per un po’.\n
- Perché le applicazioni hanno cominciato ad essere “un po’ troppo accoppiate” e tirare secchiate d’acqua sul server non ha aiutato a risolvere il problema.\n
- \n
- \n
- \n
- \n
- \n
- \n
- Finché qualcuno, finalmente ha avuto un’idea.\n
- Sì, applichiamo SOA, la soluzione migliore contro il troppo accoppiamento. Cominciamo con il disaccoppiare la presentation dal database, così “possono cambiare”\n\n... solo che però non cambiano.\n
- E ... non si doveva disaccoppiare anche la persistenza? Ed andare verso i Business Autonomous Components?\n
- ... una cosa alla volta. Intanto abbiamo messo uno strato a servizi. E questo basti. non si può fermare il progresso.\n
- Quindi, questa è la SOA più diffusa.\n
- Che sul nostro schema architetturale è un po’ come insegnare ai maiali a mangiare con le posate. È sempre la stessa sbobba nella stessa vasca, ma almeno i maiali sembrano più educati\n
- Però c’è un’altro problema... perché nonostante si parli di SOA nella nostra testa continua ad esserci un’altra cosa. Proviamo a fare un’esempio di una gestione magazzino. Molto semplice.\n
- Il fornitore consegna l’articolo 1234. Aggiorno il record corrispondente.\n
- Spedisco 50 articoli al cliente, aggiorno la giacenza dell’articolo corrispondente.\n
- Nel caso il magazziniere abbia fatto danni con il muletto, la situazione non cambia molto.\nAggiorniamo la giacenza, rimuovendo dal conteggio i preziosissimi pezzi rotti.\n
- Qualche pezzo non si trova (se lo sono rubato?) come trattiamo la situazione? Alla stessa maniera!\n
- Poi qualcuno inspiegabilmente riappare, magari è stato semplicemente appoggiato nel posto sbagliato. Cose che capitano.\n
- Sul reso le cose si fanno più difficili. Dobbiamo prima verificare in quali condizioni, ma non è che questa funzionalità sia stata proprio implementata...\n
- Poi a fine anno si fa un bell’inventario e si aggiornano i conti con la disponibilità effettiva.\n
- Peccato che non vi sia traccia sul database di queste operazioni.\n
- Per cui ad un certo punto arriva una bella richiesta di poter tracciare con esattezza che cosa succede. Chi modifica i dati e perché.\n
- Per cui ad un certo punto arriva una bella richiesta di poter tracciare con esattezza che cosa succede. Chi modifica i dati e perché.\n
- Per cui ad un certo punto arriva una bella richiesta di poter tracciare con esattezza che cosa succede. Chi modifica i dati e perché.\n
- Ideona!\n\n(ci risiamo)\n
- Un bel meccanismo di logging, che intercetta tutto l’intercettabile.\n
- E quindi ci agganciamo dove possiamo e scriviamo, su DB, su file system o ...dove capita, un bel flusso continuo di informazioni che si va ad affiancare al supporto persistente.\n\nLo facciamo un po’ come capita. Non è che ci siano tutte queste linee guida stringenti sul logging.\n\nA parte quella - non scritta - di scrivere un wrapper per Log4J.\n
- Quindi se questo era il nostro schema di partenza,\n
- ...mettiamo una bella telecamera a circuito chiuso per controllare che i maiali non facciano nulla di male.\n
- E creiamo un bel centro di controllo che 24 ore su 24 stia ad osservare cosa fanno i maiali registrando ogni loro mossa.\n
- ma anche così, ogni tanto qualcosa passa.\n
- C’è qualcosa di sinistro nelle aziende che dicono “i dati sono il cuore del nostro sistema”. È come una ragazza che conosci all’aperitivo e ti dice: “sai, io non potrei vivere senza ossigeno...” non è il modo più intelligente per impostare una conversazione!\n
- Ma la cosa singolare è che la maggior parte delle aziende che considerano i dati il proprio asset principale sono anche quelle che li trattano peggio.\n
- Anzi sono proprio loro ad avere più problemi.\n
- Peccato, ragazzi. \n
- Il punto è che non è che i dati siano il cuore, è che avete messo il database al centro dello sviluppo.\n
- ... e quello non era il posto che gli competeva.\n\nPerché se i dati sono il cuore, non avete trovato il posto corretto per il cervello dell’applicazione. Il suo comportamento.\n
- E questa cosa è veramente una bestemmia. Ed è stupefacente, perché non ho trovato nessun libro di architettura che raccomanda questo approccio. Fowler lo cita, ma principalmente perché esiste. Non perché sia buono.\n\nLa mia domanda diventa... ma perché?\n
- E purtroppo la risposta è semplice. Si tratta del percorso più sensato assumendo di partire senza conoscere l’architettura.\n\nPer il nostro piccolo primo progetto, si tratta di un approccio che pare andare bene.\n
- È la prima cosa che possiamo fare. Non dimentichiamo che all’università ci hanno insegnato solo a fare cose piccole e semplici.\n\nCome si fanno le cose grosse? Come \n
- Solo che man mano che i requisiti arrivano, è difficile fare crescere le nostre applicazioni. Non sappiamo come fare grandi applicazioni...\n
- ...quindi le facciamo nell’unico modo che conosciamo. Come le applicazioni piccole, ma con più roba dentro.\n\nTemo che la barzelletta del “come faranno 4 elefanti a stare in una 500?” possa avere influito sulle nostre scelte.\n
- Imitiamo il comportamento di chi è arrivato prima di noi. È così che si impara, no?\n\n(se siete interessati al tema, ne parlo nell’altra mia presentazione: http://www.slideshare.net/ziobrando/fare-pip-controvento)\n
- Ci si documenta sui testi di riferimento, spesso gentilmente suggeriti dal vendor.\n
- Ed eccoci alla nostra cara vecchia situazione di partenza.\n
- Bentrovati!\n
- \n
- Ok, vi ho malmenato abbastanza. Ora provo ad essere propositivo. Cominciamo da un ingrediente che abbiamo tenuto nel congelatore per un po’ ma che è sempre buono.\n
- Le cose che cambiano assieme stanno assieme.\n
- Gli aggregati definiscono gli invarianti di comportamento (considerazione business) e sulla base di questi i confini transazionali. Perché questi siano consistenti è possibile-necessario un certo livello di duplicazione.\n
- È interessante notare che in tutte le possibili architetture di supporto a Domain-Driven Design (DDD classico, CQRS + ES, DDD con linguaggi funzionali, etc.) il concetto di Aggregato rimane sostanzialmente identico.\n
- Non è colpa dell’ORM. È che lo stiamo usando male. Per mettere assieme un modello ad oggetti incoerente con un modello dei dati sbagliato.\n
- È come fare la sfoglia. Se la fate piccola, non ci sono problemi.\nSe la fate grande... fa le pieghe.\n
- ... ma anche su questo tema sono emerse variazioni sul tema. Dal modello originale che ruotava ancora abbastanza attorno ai dati (o non diceva di non farlo) siamo arrivati a qualche implementazione che separa in maniera abbastanza drastica le informazioni necessarie alla nostra applicazione per prendere delle decisioni da quelle inutili all’applicazione ma necessarie per gli operatori, per capire cosa sta succedendo. Il software non si comporta diversamente sulla base del cognome - almeno spero - ma l’utente deve poter vedere il cognome quando sta operando.\n
- L’altra “piccola” novità nella gestione degli aggregati è stata l’affermarsi di un paradigma di comunicazione asincrona, basato sui domain events e su meccanismi di notifica.\n
- Ingrediente N°2. Questo dovrebbe essere nuovo...\n
- ...ma in realtà non lo è.\n\nPeggio, prende ispirazione dai sistemi basati su carta. Solo che la singola sorgente di verità è ora rappresentata dagli eventi. Il flusso degli eventi mima quello dell’equivalente sistema cartaceo, senza aggiunta di complessità accidentale.\n
- Non è una vera novità. Il vostro conto corrente è implementato esattamente nello stesso modo. Non è una sorpresa, perché il Conto Corrente è esattamente una di quelle cose che è un po’ pericoloso implementare come uno squallido CRUD.\n
- Possiamo ricavare lo stato dalla sequenza degli eventi.\n\nI più smaliziati noteranno anche uno stile di programmazione che inizia ad avvicinarsi al funzionale...\n
- Ma questa è forse la cosa più interessante: il sistema non ha alcuna perdita di contenuto informativo. Non ci sono cancellazioni o modifiche del dato.\n
- Ingrediente N°3 Command Query Responsibility Segregation.\n
- Architettura senza compromessi.\n\n\n
- Sul versante dei comandi, stiamo sostanzialmente dando ordini a singole entità del nostro sistema. Il sistema deve modellare il comportamento, e permettere un’evoluzione controllata sulla base delle mutevoli esigenze del business.\n
- Sul versante delle query, invece... siamo interessati a grosse moli di dati, a dati aggregati magari sotto forma di grafici o report. Ma non c’è alcuna idea di comportamento.\n\n...abbiamo bisogno di un domain model?\n
- la nostra architettura senza compromessi...\n
- è sostanzialmente questa.\n\nSul lato command, abbiamo il domain model con i nostri aggregati che ricevono comandi e producono eventi.\n\nAlcune componenti (projection) sono in ascolto sulla coda degli eventi e generano i modelli di lettura necessari all’applicazione. Praticamente posso fare a meno delle query, contando su tabelle popolate in modalità push man mano che i dati si aggiornano.\n
- Il modello è sostanzialmente push, mi aiuto con un esempio.\n
- Su un modello in cui recupero le informazioni quando è necessario, scateno le query (con il rischio di appesantire il sistema) al momento della richiesta utente. \n\nSe qualche componente non risponde, ovviamente sono guai.\n
- \n
- Se fossi stato bravo - ed ogni anno ci provo - invece avrei raccolto le fatture e tutta la documentazione necessaria, man mano che arrivava in una bella carpetta ordinata.\n\nE quando finalmente il commercialista si fa sentire, ecco che io gli passo all’istante tutta la documentazione.\n
- È esattamente di questa cosa che stiamo parlando. Solo, ad un livello di granularità maggiore.\n
- Ma c’è un modo più espressivo per dirlo.\n
- (io non ne voglio sapere nulla)\n
- Il computer è perfetto per queste cose.\n\nNotificare a voce non scala. Elettronicamente sì.\n
- L’ultimo ingrediente, dalla seconda parte del libro di Evans che non tutti hanno letto.\n
- Nella nostra applicazione enterprise ci saranno più modelli.\nCi saranno sempre.\nAnche se la implementiamo in Access (nitrito di cavallo).\nPerché i modelli hanno obiettivi diversi, sono espressi da stakeholders diversi, in linguaggi diversi.\n\nDobbiamo IMPLEMENTARLI non UNIFICARLI.\n
- Abbiamo tutti i gradi di libertà che ci servono, ma per qualche strano motivo non vediamo l’ora di rinunciarci.\n
- Gli eventi avvengono in determinati contesti e contribuiscono a definire il linguaggio caratteristico del modello.\n\nEventi prodotti in un contesto possono essere consumati in un altro contesto, eventualmente tradotti e ritrasmessi.\n
- Ma i contesti sono indipendenti\n
- (voglio essere padrone a casa mia)\n
- Ops, questa non ve l’aspettavate. Sto forse violando il DRY?\n
- No, perché la semantica è diversa. I dati sono gli stessi ma cambiano per motivi diversi.\nE quello che è editabile in un certo punto del suo ciclo di vita, è di sola lettura altrove.\n\nEd il fatto che abbiano lo stesso nome , in contesti diversi non significa che abbiano lo stesso significato o lo stesso contenuto informativo.\n
- No, perché la semantica è diversa. I dati sono gli stessi ma cambiano per motivi diversi.\nE quello che è editabile in un certo punto del suo ciclo di vita, è di sola lettura altrove.\n\nEd il fatto che abbiano lo stesso nome , in contesti diversi non significa che abbiano lo stesso significato o lo stesso contenuto informativo.\n
- No, perché la semantica è diversa. I dati sono gli stessi ma cambiano per motivi diversi.\nE quello che è editabile in un certo punto del suo ciclo di vita, è di sola lettura altrove.\n\nEd il fatto che abbiano lo stesso nome , in contesti diversi non significa che abbiano lo stesso significato o lo stesso contenuto informativo.\n
- No, perché la semantica è diversa. I dati sono gli stessi ma cambiano per motivi diversi.\nE quello che è editabile in un certo punto del suo ciclo di vita, è di sola lettura altrove.\n\nEd il fatto che abbiano lo stesso nome , in contesti diversi non significa che abbiano lo stesso significato o lo stesso contenuto informativo.\n
- No, perché la semantica è diversa. I dati sono gli stessi ma cambiano per motivi diversi.\nE quello che è editabile in un certo punto del suo ciclo di vita, è di sola lettura altrove.\n\nEd il fatto che abbiano lo stesso nome , in contesti diversi non significa che abbiano lo stesso significato o lo stesso contenuto informativo.\n
- Ancora una volta, no compromessi. Un problema alla volta.\nEd una soluzione ottimale per QUEL problema.\n\n\n
- Sono veramente requisiti in conflitto o siamo noi sviluppatori che stiamo cercando di fare mettere d’accordo persone che dicono cose diverse entrambe perfettamente lecite in contesti separati e distinti.\n\n... e se avessero ragione entrambi?\n
- Vogliamo parlare di prestazioni di questa roba?\n
- Dunque, tra una mossa e l’altra, abbiamo rimosso i conflitti di lock tra letture e scritture, introdotto un meccanismo di persistenza append-only (che quindi può essere ottimizzato senza compromessi), aperto la porta a persistenza basata su NoSQL (laddove lo si ritenga necessario), introdotto un meccanismo di push sul read model che di fatto ci elimina la necessità per le cache, introdotto la possibilità di tabelle personalizzate per le viste con caricamento ancora più rapido, aperto la strada a componenti specializzati (Event Stores) per la pubblicazione ed il salvataggio degli eventi, oltre alla possibilità di scalare orizzontalmente il read model aumentando l’hardware.\n\n... senza menzionare il set di pentole in omaggio e la splendida trapunta in lana merinos!\n
- Va come Forrest Gump quando si libera degli intralci.\n
- \n
- Non cadete nella trappola di credere che questa cosa serva esclusivamente per questioni di prestazioni.\n\nTutt’altro.\n
- Le prestazioni sono in omaggio. Il vero valore è altrove.\n
- E sta nel fatto che stiamo programmando verso un’ecosistema.\n
- Facciamo un esempio... parliamo di Sicurezza.\n
- A chi non è mai capitato di dover gestire questi problemi?\n
- A chi non è mai capitato di dover gestire questi problemi?\n
- A chi non è mai capitato di dover gestire questi problemi?\n
- A chi non è mai capitato di dover gestire questi problemi?\n
- Io li adoro. Passerei giorni in riunioni di questo genere.\n
- E l’ideona classica è...\n
- Stabiliamo un meccanismo di controllo degli accessi. Qualcosa di figo con Aspect Oriented Programming, o un bel layer trasversale, che tutto impatti.\n
- Stabiliamo le credenziali di ogni utente in maniera bella complessa.\n
- salvo poi renderci conto di una cosa...\n
- Che a livello di bounded context il problema forse era già stato risolto.\n
- E che le cose di cui le persone parlano sono le cose che devono vedere, e che noi siamo stati così fessi da metterle tutte assieme e poi da costruire un’infrastruttura per separarle.\n
- E se diamo un’occhiata a questi bei fatti di cronaca? A me preoccupa soprattutto il secondo, visto che ci sono un po’ di soldi in ballo.\n\nMa un sistema basato su Event Sourcing non può essere hackerato in questo modo. Non posso alterare i voti e non posso alterare le mucche.\n
- E se diamo un’occhiata a questi bei fatti di cronaca? A me preoccupa soprattutto il secondo, visto che ci sono un po’ di soldi in ballo.\n\nMa un sistema basato su Event Sourcing non può essere hackerato in questo modo. Non posso alterare i voti e non posso alterare le mucche.\n
- \n
- \n
- Non ho ancora finito.\n
- La vista ad eventi ha ancora qualche sorpresa in serbo\n
- \n
- Perché e esattamente il modo in cui i nostri stakeholder esprimono i requisiti. Senza query ed integrazioni imbarazzanti. Cose che succedono e cose che devono succedere. Avere un sistema che mappa a questo livello semplifica le cose immensamente.\n
- ed aiuta anche non poco a capire il reale flusso di valore all’interno dell’applicazione.\nQuello che teoricamente tutti dovrebbero conoscere, ma che nella pratica non conosce bene nessuno, anche se nessuno è nelle condizioni di ammetterlo.\n
- Fate una prova. Modellate il flusso totale. E a modellazione finita raccogliete le cose per buttare via tutto. Osservate le reazioni.\n
- Ma questo è esattamente il momento in cui iniziamo attivamente a collaborare con gli esperti di dominio. Quel modello serve a loro e serve a noi.\n
- Non ho finito.\n\nGli eventi mappano perfettamente anche i flussi di lavoro interni ai contesti. Notare le kanban board.\n
- E la cosa ci può permettere di avere un controllo fine sui flussi aziendali, ad un livello di precisione mai sperimentato prima. O mai sperimentabile... costava troppo!\n
- Ma sappiamo anche che le kanban board sono formidabili strumenti di individuazione dei colli di bottiglia. Ci dispiace così tanto poter individuare in tempo reale quale sia il collo di bottiglia a livello di azienda?\n
- L’impatto è sull’intero ecosistema, non solo sulle prestazioni dell’applicazione.\nFacciamo le cose giuste e non perdiamo tempo a fare le cose sbagliate.\nImplementiamo features che portano valore ed aumentiamo la competitività dell’azienda.\n
- E su ciascuno di questi aspetti ci sono ricadute:\n- una corretta separazione dei bounded context riduce il numero di riunioni (parlo solo con le persone realmente interessate ad un problema, sono più disponibili perché il problema è il loro problema e questo mi riduce i tempi di attesa).\n- Se tutto è negli eventi, posso ripercorrere l’esatta sequenza che mi genera un bug. Posso correggerlo retroattivamente.\n- I conflitti sui requisiti si riducono perché una buona percentuale non sono conflitti.\n- Posso sfruttare l’infrastruttura per sperimentare implementazioni alternative o strategie di gestione alternative (“vediamo cosa sarebbe successo con due magazzini invece di uno, sulla sequenza degli eventi del 2008-2009-2010”).\n
- \n
- Ogni singola mossa è valida anche da sola ed apporta chiarezza alla realizzazione, ed introduce vantaggi sia a livello di progettazione che di esecuzione. Non è necessario che tutte le mosse siano implementate.\n
- Non necessariamente, ma la sinergia è comunque positiva. Sicuramente non è necessario che tutto il sistema sia in Event Sourcing. Il punto è isolare correttamente le porzioni del sistema e capire quali sono chiave per apportare valore al business. Lì ha senso intervenire.\n
- Ma ovviamente c’è tutto il mondo delle “fasi di transizione”.\n
- Uno dei più interessanti riguarda il “cosa fare se sono una piccola impresa e non ho modo di avere un sistema di grandi dimensioni”, c’è comunque modo di avere interessanti integrazioni leggere anche a livello di coordinamento di task sostanzialmente manuali.\n\nIl fatto di avere sotto controllo un sistema che possa evidenziare i colli di bottiglia ci aiuta anche a capire qual è la prossima feature che necessita di un’automazione.\n
- C’è fermento! Ma è anche vero che Domain-Driven Design è rimasto interessante forse proprio perché non sono arrivati i vendor a vendere “cassoni” costosissimi trasformando un’impostazione architetturale sensata (SOA dei primi tempi) in un mercato delle vacche.\n
- ma sicuramente del lavoro da fare ce n’è. Non dimentichiamo che ci sono anni ed anni di calcare da togliere dai server.\n
- Facendo le cose con sale in zucca.\n
- ...perché (e qui alzo il tiro) la ripresa delle aziende dipende in larga parte da quanto siamo in grado di renderle efficienti. Si parte anche da qui. Il prima possibile.\n
- \n
- \n
- \n
- \n