Il documento discute il Domain Driven Design (DDD) come un insieme di principi per migliorare il processo di sviluppo software, enfatizzando l'importanza di una comunicazione efficace tra gli stakeholder e l'uso di un linguaggio comune. Illustra la necessità di creare modelli concettuali del dominio e separare i modelli di dominio e read model per gestire logicamente e efficacemente le operazioni di business. Presenta anche concetti chiave come aggregates, value objects, e il pattern repository per ottimizzare l'accesso ai dati.

1. Giovedì, 21 giugno 2012
Speaker: Manuel Scapolan

2. Domain Driven
Design
E’ un insieme di principi che ci
aiutano a non fallire nel processo
di sviluppo di un software *
* considerando tutte le fasi del ciclo di vita!

3. Alcuni dei più grandi
fallimenti della storia:
Sources: Business Week, CEO Magazine,
Computerworld, InfoWeek, Fortune, The
New York Times, Time, and The Wall
Street Journal.

4. DDD What?

6. Una delle principali
cause del fallimento di
un software è la scarsa
comunicazione con
gli stakeholder …

7. E’ necessario anticipare il momento in
cui cominciamo a capirci qualcosa …

8. Ubiquitous Language
E’ importante conoscere e utilizzare lo
stesso vocabolario degli esperti di
dominio (domain experts) per poterlo
poi condividere a tutti i livelli,
fino al codice!

9. Parlare tutti lo stesso
linguaggio dall’esperto di
dominio, all’analista fino
allo sviluppatore, significa
portare nel codice i
termini comunemente
utilizzati dal business.
Vuol dire che devo scrivere
il codice in italiano???
In nome dell’Ubiquitous
Language può essere
necessario …

10. Domain Model
La conoscenza deve essere tradotta in
un modello concettuale il più possibile
fedele alla realtà da rappresentare
secondo lo scopo dell’applicazione che
ne deve fare uso

11. Domain Model Pattern
“An object model of the domain that
incorporates both behavior and data”
Martin Fowler
PoEAA

12. Mi stai forse dicendo che
fare Domain-Driven
Design significa realizzare
un modello ad oggetti che
rifletta la realtà che
l’applicazione dovrà
gestire?
Non lo facevamo già
questo con l’OOP?
Ci sono forse delle
indicazioni su come devo
disegnare le mie classi?

13. Model-Driven Design - Building Blocks
2004 - Eric Evans

14. Entities
Elementi del dominio identificati in modo
univoco indipendentemente dai valori dei loro
attributi che possono variare nel tempo
public class Order : IEquatable<Order>
{
public bool Equals(Order other)
{
return this.Id.Equals(other.Id);
}
}

15. Value Objects
Elementi del dominio identificati attraverso
l’insieme dei loro attributi, generalmente
immutabili, l’unico cambiamento è dato dalla
completa sostituzione (no side-effect)
public class ShippingAddress : IEquatable< ShippingAddress >
{
public bool Equals(ShippingAddress other)
{
return this.Street.Equals(other. Street)
&& this.PostCode.Equals(other.PostCode)
&& this.City.Equals(other.City);
}
}

16. Garantiscono al loro
interno la consistenza
Aggregates delle informazioni

17. L’aggregato segue alla
perfezione la regola
dell’incapsulamento in
quanto le entità e i value
object che lo compongono
non possono essere
acceduti direttamente, ma
devono essere manipolati
attraverso l’entità definita
come aggregate root.
Ma allora come faccio
l’accesso ai dati?

18. Repository Pattern
“Mediates between the domain and data
mapping layers using a collection-like interface
for accessing domain objects.”

19. Architettura N-Tier

20. Diapositiva lasciata intenzionalmente bianca
20

21. Informazioni generali sul
prodotto
Informazioni statistiche
sui prodotti correlati
21

22. “A single model cannot be appropriate for
reporting, searching, and transactional
behaviors…”
Greg Young

23. Informazioni statistiche
aggiornate periodicamente
23

24. Read Model
Per le informazioni in sola lettura
(come ad esempio quelle statistiche)
possiamo usare un modello costruito
appositamente per velocizzare
ricerche, query e filtri
Ad esempio tra le classi di questo modello potrei avere
BestSellerProductItem e BestSellerProductView

25. Domain Model
Read Model

26. Ma “two is meglio che one”!

27. Domain Model
Read Model

28. “Every method should either be a
command that performs an action, or a
query that returns data to the caller, but
not both.”
Command-query separation (CQS) principle,
Bertrand Meyer

29. Il Domain Model conserva
e gestisce la logica di
business con tutte le sue
regole. Se pensiamo alle
modifiche da applicare al
modello sono sempre il
frutto di una particolare
Domain Model richiesta o task.
Ogni richiesta può essere
benissimo tradotta
nell’esecuzione di un
comando ben preciso.

30. Una comune form di “data-entry”

31. Una versione Task-based

32. Ma come aggiorniamo la parte in
sola lettura?

33. Ci vuole qualcosa che ci avvisi che il
modello è cambiato …

34. … qualcosa come un Evento!

35. Nella parte dedicata al
Read Model una serie di
event handlers catturano
gli eventi del Domain
Model invocando dei
componenti chiamati
“Denormalizer” che
scompongono le
informazioni trasmesse
dall’evento e le utilizzano
per aggiornare il database Read Model
dedicato alla lettura.

36. … e come fa l’evento a raggiungere il
suo handler?

37. … prende il Bus!
Message Bus

39. DEMO
Vediamo un esempio di architettura CQRS

40. Event Sourcing
Se facciamo in modo che nell’evento ci sia
la logica di applicazione delle modifiche
possiamo pensare di salvare gli eventi e
avere così un sistema che mi permetta di
ricostruire lo stato di un aggregato a
partire da una serie di eventi

42. Credits
Le immagini contenute in questa presentazione delle
quali non è stata esplicitata la provenienza hanno
licenza Creative Commons
Slide 1: http://www.flickr.com/photos/26429107@N03/2508680764/
Slide 12: http://www.flickr.com/photos/14456988@N00/5730592664
Slide 17: http://www.flickr.com/photos/39384443@N00/3278857246/

43. Thank You MANUEL SCAPOLAN
website: www.manuelscapolan.it
twitter: manuelscapolan
e-mail: info@manuelscapolan.it