Event based modeling iad 2012

martedì 27 novembre 12

Obiettivi

Giungere ad un modello di un sistema complesso in tempi rapidi

fare emergere i concetti fondamentali di Domain-Driven Design senza particolari prerequisiti.


In pratica...

Srotoliamo un rotolone di carta sulla parete.

Abbiamo a disposizione 25 metri lineari di spazio per modellare

Lavoro collaborativo


Domain EventsApparente 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


Dritta:

...la cosa è molto più interessante se esploriamo collaborativamente le aree che non conosciamo.

...con l’esperto di dominio.

... con esempi concreti.


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


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


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


DefinizioneUn’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.


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


Invarianti

Dimentichiamo il dato:L’aggregato può accettare o rifiutare il comando.

Sulla base di quali informazioni?

Cosa è sempre garantito per il nostro aggregato?


AggregatiLa 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

EsempioLimite 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


SubdomainsRappresentano 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.


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...


Bounded Contexts

Evidenziano i diversi modelli in giocoApplicazioni software

Componenti legacy

Linguaggi utilizzati

Sono una foto della realtà, non di come vorremmo che fosse.


Users & PersonasPossiamo 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


TestsDurante 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 :-)


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


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...


Sistemi LegacyIl 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


Event based modeling iad 2012

Technology

Transcript of Event based modeling iad 2012