Your SlideShare is downloading. ×
Event based modeling iad 2012
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Event based modeling iad 2012

2,127

Published on

Scan delle sldes di accompagnamento del workshop su Event-Driven modeling all'Italian Agile Day - Milano 2012

Scan delle sldes di accompagnamento del workshop su Event-Driven modeling all'Italian Agile Day - Milano 2012

Published in: Technology
3 Comments
22 Likes
Statistics
Notes
No Downloads
Views
Total Views
2,127
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
279
Comments
3
Likes
22
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. martedì 27 novembre 12
  • 2. Obiettivi Giungere ad un modello di un sistema complesso in tempi rapidi fare emergere i concetti fondamentali di Domain-Driven Design senza particolari prerequisiti.martedì 27 novembre 12
  • 3. martedì 27 novembre 12
  • 4. In pratica... Srotoliamo un rotolone di carta sulla parete. Abbiamo a disposizione 25 metri lineari di spazio per modellare Lavoro collaborativomartedì 27 novembre 12
  • 5. Domain Events Apparente parentela con un Activity Diagram ...ma non stiamo facendo UML Gli eventi non possono essere messi in discussione. Sono avvenuti. Prendiamone atto. Visione d’insieme Tutti i team tendono a “partire per la tangente” immaginando un dominio, invece che chiedere all’esperto di dominio. Il sistema reale potrebbe risultare molto più semplice Il sistema reale potrebbe risultare molto più complessomartedì 27 novembre 12
  • 6. Dritta: ...la cosa è molto più interessante se esploriamo collaborativamente le aree che non conosciamo. ...con l’esperto di dominio. ... con esempi concreti.martedì 27 novembre 12
  • 7. martedì 27 novembre 12
  • 8. origine degli eventi Gli eventi non nascono dal nulla: alcuno nascono in risposta ad azioni degli utenti altri nascono in sistemi esterni altri sono originati dallo scorrere del tempo ...altri sono generati in risposta ad altri eventimartedì 27 novembre 12
  • 9. martedì 27 novembre 12
  • 10. martedì 27 novembre 12
  • 11. Event Flow Ricerchiamo antefatti e conseguenze dei nostri eventi Il trucco del participio passato aiuta a chiarire la semantica: “matrimonio” non è un evento (ma non ditelo a vostra moglie/marito) Più attori entrano nel nostro sistemamartedì 27 novembre 12
  • 12. martedì 27 novembre 12
  • 13. Aggregates “Come definire correttamente gli aggregati?” questa è la questione che arrovella ogni DDD practitioner fate un giro su DDD-IT, se non ci credete L’obiettivo di questo esperimento è di arrivare ad una loro definizione per una strada diversa dal solitomartedì 27 novembre 12
  • 14. Definizione Un’aggregato rappresenta una unità di consistenza: un gruppo di oggetti il cui stato cambia simultaneamente. ...ma così non è molto chiaro... ...quanto sono grandi questi oggetti? ...come sono fatti? Ha a che fare con i confini transazionali, ma non è detto che i nostri siano Ok.martedì 27 novembre 12
  • 15. Rule of thumb Per individuare cosa fa parte dell’aggregato possiamo pensare a Informazioni che vengono cancellate assieme Informazioni che vengono spostate assieme Informazioni che vengono distribuite assiememartedì 27 novembre 12
  • 16. Invarianti Dimentichiamo il dato: L’aggregato può accettare o rifiutare il comando. Sulla base di quali informazioni? Cosa è sempre garantito per il nostro aggregato?martedì 27 novembre 12
  • 17. martedì 27 novembre 12
  • 18. Aggregati La prospettiva basata sulle invarianti aiuta a modellare correttamente gli aggregati Mi limito ad una dimensione che posso controllare Propago le variazioni con Domain Events Esploro correttamente il dominio Il sistema è eventualmente consistentemartedì 27 novembre 12
  • 19. Esempio Limite massimo di partecipanti per classe: Da dove deriva? Limite logistico aula? --> accetto e tratto per una location più adatta Limite fisiologico corso --> stand-by e tratto per una nuova edizione Non impongo requisiti non presenti nel sistemamartedì 27 novembre 12
  • 20. martedì 27 novembre 12
  • 21. Subdomains Rappresentano la visione business del sistema Alcune porzioni sono fondamentali per la competitività della nostra azienda. Es contenuti su web, marketing, quello che ci fa vendere qualcosa in più. Altre sono semplicemente necessarie. Es. fatturazione: serve, ma non avremo nessun cliente un più per la bellezza ed il tempismo delle nostre fatture.martedì 27 novembre 12
  • 22. Linguaggi In aziende di medie dimensioni i referenti sono diversi. Hanno obiettivi diversi Parlano lingue diverse ...richiederanno modelli diversi Attenzione: non stiamo parlando (ancora) dei Bounded Contexts...martedì 27 novembre 12
  • 23. martedì 27 novembre 12
  • 24. Bounded Contexts Evidenziano i diversi modelli in gioco Applicazioni software Componenti legacy Linguaggi utilizzati Sono una foto della realtà, non di come vorremmo che fosse.martedì 27 novembre 12
  • 25. martedì 27 novembre 12
  • 26. Users & Personas Possiamo aggiungere informazioni relative agli utenti, o alle loro famiglie Possiamo evidenziare le caratteristiche chiave delle personas e renderle parte del modello... ...specialmente se questo genera una conversazione interessante con gli esperti di dominiomartedì 27 novembre 12
  • 27. martedì 27 novembre 12
  • 28. Tests Durante la conversazione emergono dettagli che ha senso catturare in un test. Scritto in linguaggio naturale ...secondo gli schemi BDD (--> Cucumber) In una prospettiva ad eventi, la struttura Given [events] When [command] Then [event] è molto interessante :-)martedì 27 novembre 12
  • 29. martedì 27 novembre 12
  • 30. Takeaways Siamo riusciti a modellare un sistema complesso ignorando i dati ... e se il data model fosse parte del problema? Abbiamo mantenuto il focus sul comportamento del sistema e non sulla struttura staticmartedì 27 novembre 12
  • 31. Takeaways Questo modello ha valore anche come strumento di apprendimento collettivo, e come visione di insieme (non è detto che gli esperti di dominio sappiano già tutto) Il tempo è tiranno, ma... Lo spazio è tiranno, ma...martedì 27 novembre 12
  • 32. martedì 27 novembre 12
  • 33. Sistemi Legacy Il modello che abbiamo costruito è molto vicino ad un “modello ideale” del sistema NON è il punto di partenza per rifare tutto! Ma è un buon punto di riferimento per stabilire una direzione Componenti legacy che non fanno parte del dominio, emergono come complessità accidentale. Operazioni batch, foglietti che non sapete dove piazzare... ...sono fuori posto come uno squatter alla prima della Scalamartedì 27 novembre 12

×