1. Scalable Architecture for the Cloud

2. What????  Command Query Responsibility Segregation  What is it?  What kinds of apps is it for?  What are the moving parts?  What does it buy me?  How do I do this on Azure?

3. What is it?  An architectural pattern  Embracing modern requirements  Self service  High scalability  Asynchronous processing

4. Applicability  Multiple simultaneous users  Untrained users  We’ll be talking about the web

5. Applicability  Usage patterns  More reads than writes  No really, more reads than writes  Lots, lots, lots more

6. Applicability  Asynchronous Processing  “Thank you, you will receive a confirmation email shortly.”

7. 3-Tier Architecture UI Domain DB READ WRITE

8. Is it really symmetric?  Reads  Fast  Synchronous  Idempotent  Stale  Writes  Slow  Asynchronous  Stateful  Current

9. Sidebar  Command Query Separation  Methods should either:  Query State and return a value  Or Execute behavior and return nothing  Bertrand Meyer

10. CQRS Architecture UI DOMAIN DB

11. CQRS Architecture UI WRITE MODEL WRITE DB READ MODEL READ DB READ WRITE Q

12. Read Model / Store  Optimized for Reading  Denormalized out the wazoo!  Matches UI model requirements  No logic – DTO  One “table” per screen  SELECT * FROM TABLE WHERE …  No joins  It’s a cache, not a database!

13. Write Model / Store  Accepts Commands  Executes Business Rules  Generates Business Events

14. Write / Read Side Sync  Processes Domain Events  Updates tables in read store

15. What’s a Command?  A message  Named in the imperative  AddNewUser  PublishDocument  LaunchMissiles  Task Oriented

16. Command Processing  UI Validates before sending  UI Sends command  Write model re-validates  Write model processes business rules  Write model generates events  Assume commands will succeed most of the time

17. What’s an event?  A message  Named in the past tense  UserAdded  NewDocumentPublished  WentBoom  Express Changes in the domain over time  Save the event stream for reprocessing

18. Event Processing  Receive events as they come out  Update read stores

19. How is this scalable?  Web Farms  Event Processors  Read Stores  Harder to scale the write side  But we have lots more reads anyway

20. Other Advantages  External System Integration  Events write to external system  Commands when external system wants you to do something  You know it works, you’re using it!

21. Mapping to Azure  Queues  Table Store  Event Store  Read Stores  Worker role  Command processors  Event Processors  Web role  Front end

22. Show me some code!

23. A special bonus pattern!

24. What is event sourcing?  Model Persistence  ORM  We’re generating events anyway  Events record changes to the domain over time  So we know every state change that’s happened anyway

25. Event Sourcing  Load domain entities by “playing back” domain events  No need for ORM  Use snapshots for efficiency

26. Resources  Udi Dahan  http://www.udidahan.com http://www.udidahan.com  Greg Young  http://codebetter.com/blogs/gregyoung/ http://codebetter.com/blogs/gregyoung/  http://cqrs.wordpress.com/ http://cqrs.wordpress.com/  Mark Nijhof  http://cre8ivethought.com/blog/index http://cre8ivethought.com/blog/index  http://www.agilification.com/post/CQRS-Series- from-Mark-Nijhof.aspx http://www.agilification.com/post/CQRS-Series- from-Mark-Nijhof.aspx

27. Questions?