Domain Driven Design e CQRS
4 likes5,206 views
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.
Domain Driven Design e CQRS
- 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.”
- 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
- 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”
- 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