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

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 collaborativo
martedì 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ù complesso
martedì 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
eventi
martedì 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 sistema
martedì 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 solito
martedì 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 assieme
martedì 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 consistente
martedì 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
sistema
martedì 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 dominio
martedì 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 static
martedì 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
Scala
martedì 27 novembre 12