Stai guardando i dati sbagliati

3,885
-1

Published on

Better Software 2012 - Questo è il mio talk sull'architettura software. Si parla di DDD, Event Sourcing, Bounded Contexts, SOA, maiali e simili.

Published in: Technology
4 Comments
18 Likes
Statistics
Notes
No Downloads
Views
Total Views
3,885
On Slideshare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
70
Comments
4
Likes
18
Embeds 0
No embeds

No notes for slide
  • \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
  • Stai guardando i dati sbagliati

    1. 1. Stai guardando idati sbagliati @ziobrando
    2. 2. About meIn the IT field since ZX SpectrumGenerally in large scale projects (I might bebiased)Strategic IT ConsultantTrainer (Avanscoperta & Skills Matter)Technical WriterBlogger: http://ziobrando.blogspot.comTwitter: @ziobrandoMy e-mail: alberto.brandolini@gmail.com
    3. 3. What I doAgile processesDomain-Driven DesignEfficiency & ManagementArchitectureFunny clown 9% 11% 38% 12% 31%
    4. 4. Preludio
    5. 5. Il problema(o quella strana situazione che riteniamo essere il problema)
    6. 6. Architettura
    7. 7. Risultatiincredibili
    8. 8. Finché...
    9. 9. JENGA!
    10. 10. Perché?
    11. 11. L’architettura più comune?
    12. 12. Data-basedApplication Application Applicationhttp://martinfowler.com/bliki/ IntegrationDatabase.html
    13. 13. 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 nDatabase a ti on pplic Databas A eData-based integration
    14. 14. Poi, su questa architettura...qualche problema è emerso.
    15. 15. Eccessivo accoppiamento
    16. 16. Allungamento tempidi sviluppo
    17. 17. Allungamento tempidi sviluppo Affidabilità in calo
    18. 18. Allungamento tempidi sviluppo Affidabilità in caloBug a sorpresa
    19. 19. Allungamento tempidi sviluppo Affidabilità in caloBug a sorpresa Riunioni, riunioni,
    20. 20. Allungamento tempidi sviluppo Affidabilità in caloBug a sorpresa Riunioni, riunioni,Notti
    21. 21. Allungamento tempidi sviluppo Affidabilità in caloBug a sorpresa Riunioni, riunioni,Notti Addio ferie
    22. 22. Potremmo applicare SOA!!!
    23. 23. SOA?Application Application Application Service Layer
    24. 24. ...e questo?Application Application Application Service Layer
    25. 25. Magari più avanti
    26. 26. SOA :-/Application Application Application Service Layer
    27. 27. Insegnareai maiali amangiare con le posate!
    28. 28. Magazzino... ID_Articolo Giacenza 1234 0
    29. 29. Magazzino... ID_Articolo GiacenzaConsegna Fornitore(100) 1234 100 UPDATE Giacenza SET Giacenza=100 WHERE ID_articolo=1234
    30. 30. Magazzino... ID_Articolo GiacenzaSpedizione a cliente(50) 1234 50 UPDATE Giacenza SET Giacenza=50 WHERE ID_articolo=1234
    31. 31. Magazzino... ID_Articolo GiacenzaDanneggiamento(12) 1234 38 UPDATE Giacenza SET Giacenza=38 WHERE ID_articolo=1234
    32. 32. Magazzino... ID_Articolo GiacenzaSmarrimento(2) 1234 36 UPDATE Giacenza SET Giacenza=36 WHERE ID_articolo=1234
    33. 33. Magazzino... ID_Articolo GiacenzaRitrovamento(1) 1234 37 UPDATE Giacenza SET Giacenza=37 WHERE ID_articolo=1234
    34. 34. Magazzino... ID_Articolo GiacenzaReso(5) 1234 ?
    35. 35. Magazzino... ID_Articolo GiacenzaControllo 1234 32Disponibilità(32) UPDATE Giacenza SET Giacenza=32 WHERE ID_articolo=1234
    36. 36. Che fine hanno fatto?• Consegna Fornitore (100)• Spedizione al cliente(50)• Danneggiamento(12)• Smarrimento(2)• Ritrovamento(1)• Reso(5)• Controllo Disponibilità(32)
    37. 37. Requirements
    38. 38. RequirementsND A
    39. 39. RequirementsND AVogliamo sapere in ogni istantequale utente ha compiuto qualeoperazione
    40. 40. RequirementsND AVogliamo sapere in ogni istantequale utente ha compiuto qualeoperazioneTutte le operazioni di accesso emodifica del dato da parte delleapplicazioni devono esseretracciate
    41. 41. Logging
    42. 42. Application Application Application Service Layer
    43. 43. C’è sempre chi scavalca
    44. 44. WeData
    45. 45. I dati sono il cuore del nostro sistemaAbbiamo un problema di dati sporchi
    46. 46. I dati sono il cuore del nostro sistemaAbbiamo un problema di dati sporchi
    47. 47. oops
    48. 48. WeData
    49. 49. What about ?
    50. 50. Come si arriva fin qua?
    51. 51. Con le migliori intenzioni
    52. 52. Da una base semplice
    53. 53. Come si fanno le cose grandi?
    54. 54. Come le piccole, solo ...più grandi!
    55. 55. Si imita...
    56. 56. Ci si documenta...
    57. 57. Sviluppi lentiBug Notti insonni ProcedureComplessità Rework Sprechi Turnover
    58. 58. Possibile che non ci sia un altro modo?
    59. 59. Mossa N°1 - AggregatesLe cose che cambiano insieme stanno
    60. 60. Aggregate boundaries? Ordinemod_spedizione VoceOrdine Articoloimporto Quantità Descrizione prezzo destinatario Clienteindirizzo
    61. 61. Cambiano per motivi diversi Ordine mod_spedizione VoceOrdine Articolo importo Quantità Descrizione prezzo prezzo descrizione Destinatario indirizzo Cliente indirizzo
    62. 62. Gli aggregati sonoparte del modello
    63. 63. ...e smettiamo di dare la colpa all’ORM!
    64. 64. Quali attributi sono necessari per ilcomportamento?
    65. 65. Notifica al resto del sistema mediante Domain Events
    66. 66. Mossa N°2 - Event SourcingLa verità è nel flusso degli eventi
    67. 67. The paper based system
    68. 68. Lo stato del sistema è il risultato della sequenza deglieventi che lo hanno interessato
    69. 69. Cart.CreateEmpty().apply(ItemAdded(...)).apply(ItemAdded(...)).apply(ItemAdded(...)) => Il carrello è attivo
    70. 70. Non c’è perdita di informazione
    71. 71. Mossa N°3 - CQRSCommand/Query Responsibility
    72. 72. No compromessi
    73. 73. Command! Indirizzati ad entità singole il comportamento è importante la Flessibilità è importante © Alberto Brandolini - 2010
    74. 74. Query Grosse quantità di dati? Non c’è comportamento le Prestazioni sono importanti Disponibili numerosi componenti off-the shelf © Alberto Brandolini - 2010
    75. 75. ! Architettura ottimizzata per i comandi? Architettura ottimizzata per le letture
    76. 76. Domain Model Command Aggregate Event Event store Event Event Event UI Event Command Aggregate Event EventPresentatio UI n Event UI Projection DTO Projection UI DTO Read Model
    77. 77. Come non fare ladichiarazione dei redditi
    78. 78. Cara... Ti ricordi dove homesso i documenti sanitari?
    79. 79. Come fare ladichiarazione dei redditi
    80. 80. Tell don’t Ask
    81. 81. o ...tradotto in romagnolo
    82. 82. Me a ni vò savê gnît
    83. 83. ComputerOttimo nelleoperazioni ripetitive.Si ricorda di fare lecoseNotifica con facilità
    84. 84. Mossa N°4 - Bounded ContextsDefiniamo i reali confini delle componenti
    85. 85. Più modelli Product Delivery Publishingdevelopment Sales Marketing Customer Care Payments
    86. 86. Bounded Context• Linguaggio consistente all’interno• Un obiettivo ben preciso•Interlocutori ben definiti•Modelli indipendenti•Possibilità di scelte strategiche indipendenti
    87. 87. Eventi e Contesti Item delivered Item OrderProduct Available ReceivedDesigned 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
    88. 88. Accesso esclusivoL’appetito vien mangiando
    89. 89. Me a voj esrpadrò’ in tla mi ca’
    90. 90. Possibili piùrappresentazioni dello stesso concetto
    91. 91. Offerta != Contratto
    92. 92. Offerta != ContrattoBozza != Contratto
    93. 93. Offerta != ContrattoBozza != Contratto Carrello != Ordine
    94. 94. Offerta != ContrattoBozza != Contratto Carrello != Ordine Ordine != Ordine
    95. 95. Offerta != Contratto Bozza != Contratto Carrello != Ordine Ordine != OrdineSorgente != eseguibile
    96. 96. No compromessi
    97. 97. Requisiti in conflitto?
    98. 98. Prestazioni?
    99. 99. No conflitti lockappend only NoSQL eventual consistency data push modeltable per view Event no queries Stores Scalabilità su read
    100. 100. ma...
    101. 101. Non solo velocità
    102. 102. Non dobbiamo fare gli stessi errori più in fretta
    103. 103. Stakeholders
    104. 104. Sicurezza?
    105. 105. Requirements
    106. 106. RequirementsND A
    107. 107. RequirementsND AL’utente X non deve poteraccedere all’informazione A
    108. 108. RequirementsND AL’utente X non deve poteraccedere all’informazione AI campi della tabella K devonoessere filtrati perché gli utenti Ye Z non possano vederli.
    109. 109. RequirementsND AL’utente X non deve poteraccedere all’informazione AI campi della tabella K devonoessere filtrati perché gli utenti Ye Z non possano vederli.L’informazione N deve essere disola lettura per l’utente W
    110. 110. Interessante...
    111. 111. Mettiamo il badge ai maiali!
    112. 112. Testo rity ec u a ls S d en ti cre
    113. 113. Bounded Context? Product Delivery Publishingdevelopment Sales Marketing Customer Care Payments
    114. 114. Cose di cui parloCose a cui devo avere accesso
    115. 115. Il sistema èappend-only
    116. 116. Non possoinserire dati “a manazza”
    117. 117. Non è tutto qui...
    118. 118. Event view Item delivered Item OrderProduct Available ReceivedDesigned 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
    119. 119. ...e sulle relazioni Item delivered Item OrderProduct Available ReceivedDesigned 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
    120. 120. Requisiti al bacio Quando il cliente effettua un ordine deve essere spedita un’e-mail di confermaDato un cliente registrato XQuando X effettua un ordineAllora il sistema dovrebbe spedire un e-mail
    121. 121. Value flow Product Delivery Publishingdevelopment Sales Marketing Customer Care Payments
    122. 122. Sicuri che siachiaro a tutti?
    123. 123. gli esperti ci e noiaiutano a capire aiutiamo loro © Alberto Brandolini 2009
    124. 124. Flussi di lavoro Item delivered Item OrderProduct Available ReceivedDesigned 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 AcceptedDesign Test Ready Payment Type Payments Selected Payment To do Doing Ready New Working Resolved Refused
    125. 125. See the whole?
    126. 126. Kanban Board = Bottleneck Detector
    127. 127. Ecosistema
    128. 128. Riunioni? Bug?Conflitti? Esperimenti?
    129. 129. Riunioni? Bug?Conflitti? Esperimenti?Valore?
    130. 130. Conclusioni
    131. 131. Ogni mossa porta valore
    132. 132. Devo farle tutte? No, ma...
    133. 133. Implementazioni parziali
    134. 134. Ottimizzazione percorsi di crescita
    135. 135. Strumenti... geteventstore.co
    136. 136. Rimboccarsile maniche!
    137. 137. Ripresa?
    138. 138. Domande?
    139. 139. Grazie!@ziobrandoalberto.brandolini@avanscoperta.it
    140. 140. Implementing Domain-Driven DesignVaughn Vernonhttp://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
    141. 141. Domain-Driven DesignEric Evans Enterprise Integration PatternsGregor Hohpe, Bobby WoolfPatterns of EnterpriseApplication ArchitectureMartin Fowler Per saperne di più... www.avanscoperta.it
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×