Uno sguardo a CQRS ed EventSourcing

1,325 views

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,325
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Anaemic domain modelDTOOttimizzazione query ORMDevelopment timeTestability
  • Separazionetra I due contesti:ScritturaLetturaNOTA: sono due bounded context
  • Separazionetra I due contesti:ScritturaLetturaNOTA: sono due bounded context
  • Gli oggetti del dominio non sono “pensati” per soddisfare le esigenze della UIAccoppiamento forte tra DomainModel e UIDifficoltà nel refactoring del modello
  • Gli oggetti del dominio non sono “pensati” per soddisfare le esigenze della UIAccoppiamento forte tra DomainModel e UIDifficoltà nel refactoring del modello
  • Gli oggetti del dominio non sono “pensati” per soddisfare le esigenze della UIAccoppiamento forte tra DomainModel e UIDifficoltà nel refactoring del modello
  • Gli oggetti del dominio non sono “pensati” per soddisfare le esigenze della UIAccoppiamento forte tra DomainModel e UIDifficoltà nel refactoring del modello
  • Gli oggetti del dominio non sono “pensati” per soddisfare le esigenze della UIAccoppiamento forte tra DomainModel e UIDifficoltà nel refactoring del modello
  • Uno sguardo a CQRS ed EventSourcing

    1. 1. Uno sguardo a CQRS ed eventsourcing<br />Alessandro Melchiori<br />alessandro@codiceplastico.com<br />http://blogs.ugidotnet.org/amelchiori<br />http://twitter.com/amelchiori<br />
    2. 2. Domain Model<br />An object model of the domain thatincorporatesbothbehavior and data<br />[Martin Fowler- http://martinfowler.com/eaaCatalog/domainModel.html]<br />
    3. 3. Un’architettura per tutti i gusti…<br />DTO<br />Presentation Layer<br />Remote Facade<br />ORM<br />Application Service<br />DTO<br />Domain Model<br />
    4. 4. Domain Model<br />Class F<br />Class D<br />Class A<br />ClassB<br />ClassB<br />ClassB<br />IList<ClassE><br />IList<ClassE><br />IList<ClassC><br />IList<ClassA><br />Class B<br />…<br />Class G<br />Class C<br />ClassD<br />…<br />Class E<br />IList<ClassC><br />ClassB<br />
    5. 5. Domain Driven Design<br />Use AGGREGATES asunit of consistencyacrossyour domain model<br />Protectyour model with clearlydefined BOUNDED CONTEXT<br />Il mio amico Eric Evans <br />
    6. 6. Un’architettura per tutti i gusti…<br />DTO<br />Presentation Layer<br />Remote Facade<br />ORM<br />Application Service<br />DTO<br />Domain Model<br />
    7. 7. Aggregate e BoundedContext<br />Class A<br />Class D<br />ClassB<br />ClassB<br />IList<ClassC><br />Class B<br />Class B<br />…<br />…<br />Class C<br />…<br />
    8. 8. Domain Events<br />It’sreallybecomeclear to me in the last couple of yearsthatweneed a new building block and thatis the Domain Events<br />Sempre il mio amico Eric Evans <br />
    9. 9. Domain Events<br />Class A<br />Class D<br />ClassB<br />ClassB<br />IList<ClassC><br />Class B<br />Class B<br />…<br />…<br />Class C<br />…<br />
    10. 10. Qual è il problema?<br />Edit DTO in UI<br /><ul><li>Aggiunta di un campo sulla UI
    11. 11. Aggiunta di una property sul DTO
    12. 12. Aggiuntadella property sul DM
    13. 13. Mapping tra DTO e DM
    14. 14. Mapping ORM
    15. 15. Aggiunta campo sul DB</li></ul>Send DTO to server<br />Map DTO to model<br />Save model to DB<br />BORING!!!!<br />
    16. 16. Qual è il problema?<br />A single model cannot be appropriate for reporting, searching and transactionalbehavior<br />Greg Young, 2008<br />
    17. 17. …ripartiamo da qui…<br />DTO<br />Remote Facade<br />ORM<br />Application Service<br />DTO<br />Presentation Layer<br />Domain Model<br />
    18. 18. …ripartiamo da qui…<br /><ul><li>C’è comportamento?
    19. 19. Abbiamo necessariamente bisogno di un “modello”?
    20. 20. Abbiamo bisogno di integrità referenziale e normalizzazione?
    21. 21. Possiamo accontentarci di dati “quasi” istantaneamente aggiornati?</li></ul>Presentation Layer<br />
    22. 22. …ripartiamo da qui…<br />DTO<br />Presentation Layer<br />Remote Facade<br />ORM<br />Application Service<br />DTO<br />Domain Model<br />
    23. 23. …ripartiamo da qui…<br /><ul><li>Il domain model non nasce per “collezionare” o mostrare dati
    24. 24. Il domain model deve sempre essere in uno stato consistente</li></ul>Domain Model<br />
    25. 25. Commandqueryseparation<br />Every method should either be a command that performs an action, or a query that returns data to the caller, but NOT BOTH.<br />Bertrand Meyer<br />
    26. 26. CQRS<br />WRITE<br />Remote Facade<br />Remote Facade<br />App. Service<br />ORM<br />Command<br />Query<br />DM<br />Presentation Layer<br />Thin read layer<br />Result<br />READ<br />
    27. 27. CQRS<br />Remote Facade<br />Remote Facade<br />App. Service<br />ORM<br />Command<br />Query<br />DM<br />Events<br />Presentation Layer<br />Thin read layer<br />Result<br />
    28. 28. CQRS<br />Gli aggregate root ricevono Command e pubblicano eventi<br />L’aggiornamento della base dati in lettura avviene tramite la gestione degli eventi<br />Tutte le query impattano su una base dati “dedicata” e non coinvolgono il domain model<br />Separazione delle competenze<br />
    29. 29. Eventsourcing<br />State transition are an important part of ourproblemspace and should be modeledwithinour domain<br />Greg Young, 2008<br />
    30. 30. Eventsourcing<br />storing structure<br />order<br />items<br />shipping<br />info<br />
    31. 31. Eventsourcing<br />storing deltas<br />cart<br />created<br />add<br />item<br />add<br />item<br />remove<br />item<br />add<br />shop info<br />
    32. 32. Eventsourcing<br /><ul><li>Ogni cambiamento di stato è rappresentato da un evento
    33. 33. Ogni evento è memorizzato in un EventLog / EventQueue
    34. 34. E’ possibile aggiungere “listener” in corso d’opera</li></li></ul><li>Eventsourcing<br /><ul><li>Lo stato corrente è “costruibile” (ri)eseguendo gli eventi
    35. 35. I dati non sono persistiti in “strutture”, ma come serie di transazioni di stato</li></ul>2<br />3<br />4<br />5<br />6<br />7<br />8<br />1<br />snapshot<br />
    36. 36. Benefits<br /><ul><li>No object-relationalimpedencemismatch
    37. 37. Sistema “nativo” di auditing e tracking
    38. 38. Possibilità di “rieseguire” la pipeline degli eventi
    39. 39. bug fix – ricostruzione scenari produzione
    40. 40. si possono aggiungere feature “retroattive”</li></li></ul><li>Quando CQRS fa per me?<br />Chiedilo al “tuo” UBIQUITOUS LANGUAGE<br />
    41. 41. Quando CQRS fa per me?<br />TacklingComplexity in the Heart of Software <br />
    42. 42. Contatti<br />alessandro@codiceplastico.com<br />http://blogs.ugidotnet.org/amelchiori<br />http://twitter.com/amelchiori<br />

    ×