This document discusses the architectural pattern of Command Query Responsibility Segregation (CQRS). It summarizes that CQRS separates read (query) and write (command) operations into different models to allow for more scalability and performance. Queries use a read-only data store optimized for reading, while commands express user intentions and are validated before being asynchronously processed to update data. The pattern allows for eventual consistency by keeping query data slightly stale, and improves scalability by allowing separate optimization of queries and commands.

1. High-Performance Distributed Systems withCommand/Query Responsibility SegregationJonathan OliverUtah Code Camp 2010

2. Think DifferentlierBest practices != best thinkingBlind vs intentional applicationQuestion everythingHow much does it cost?

3. Domain Muddling and ModelingWhat was the original intent?Screen-based aggregate roots?Show domain state?Validation?Get/set, go!

4. Distributed Systems Architecture

5. Optimistic and Pessimistic StalemateCollaborative usersCurrent state?Get dataGet dataStale dataUpdate data

6. LayeringitisWhy go through all the layers?

7. Tiers for FearsWhy transform across the tiers?DTOs: more code, tests, maintenance, $$$Pre-transformed?

8. CQRS: Gotta Keep ‘Em SeparatedSOLID, Architectural “S”

9. Query Query Quite “Contrery”Showing dataQuery-only storageKISS, YAGNIIf it’s stale anywayList of Customers---------------------------------------------------------------(from 10 minutes ago)

10. All Your Database Are Belong To UsScreen-based viewsUnDRY your data—data duplication“Persistent View Model”Storage/database requirementsScaling outSELECT * FROM Carts WHERE ID = 456;

11. Queries: SummaryStale data“Persistent View Model”For queries onlyOne table per viewUpdated by eventsData duplication is goodNo table relationshipsNo foreign keys

12. Command & ConquerSay what?What is a command?Intention revealingSaveInvoicevsPlaceOrderSaveCustomervsMakeCustomerDelinquent

13. UI DesignExcel-based UIsTask-based UIs

14. This Time It’s Gonna Be DifferentCan we fully trust user decisions?

15. Commands and ValidationValidationIs the input potentially good?Ranges, lengths, etcFail fastLeverage persistent view modelUnique emails?Decides if a command should be sentEnables high probability of success

16. Business RulesShould we do this?Based upon the current system state

17. Commands: SummaryExpresses intentReply is: “Thank you, we’ve received your input.”AsynchronousAmazonNetflix

18. Domain Models, Take 2Commands already validatedNo relationships for readingOnly persists what it needsBehavior: Give discounts to high-volume customers

19. The Big PictureImage courtesy Udi Dahan

20. The Big Picture: SummarySimple 2-tier queriesCommands express intentTask-based UI captures intentSmaller, more focused pieces

21. Questions?