1. The document discusses the Command Query Responsibility Segregation (CQRS) pattern for separating queries from commands in distributed systems. It advocates keeping queries simple with a two-tier architecture without data transfer objects. 2. It also recommends designing user interfaces to capture user intent, having commands reflect that intent. Validation should be simple and business rules focused. 3. The CQRS pattern publishes commands asynchronously to improve scalability. Domain models only persist needed data and implement business logic rather than queries or validation.

1. Command / QueryResponsibility Segregation Udi Dahan – The Software Simplist Enterprise Development Expert & SOA Specialist

3. What will you see here? Some History Distributed Systems Architecture UI Design Domain Model What won’t you see here? Code

4. History

5. Paper ruled the world

6. And then came the computer

7. And with it data entry

8. And efficient UIs were designed for it

9. Source of truth

10. And then… the paper was gone Well, not GONE gone It just wasn’t the source of truth any more Now, it’s the machine

11. But the UI lingers to this day

12. No change to architecture either

13. Distributed Systems Architecture

14. Common Distributed Architecture DB

15. Let’s deal with the obvious…

16. Collaboration is good – isn’t it ? Get data Get data User is looking at stale data Change data

17. So why go through all the layers? Cache DB

18. Why transform between tiers? Cache UI WS DB Map from DTOs & WS to view model Map from DTOs and WS to domain object Use EF to map from tables to domain objects

19. What was the point of all this again?

20. Queries – showing data to the user

21. Why not be upfront about it? List of customers Data correct as of 10 minutes ago

22. Only data, no behavior There is no object So why use an Object/Relational Mapper?

23. Keep it simple - 2-Tier 2 Layers == 2 Tiers UI Query only Persistent View Model For each view in the UI, have a view/table in the DB SELECT * FROM MyTable (WHERE ID = @ID)

24. Search First think about what the user wants to find Design some custom screens for that Eg. Amazon recommendations Separate UI talking to different data store SQL Server Full Text Search Lucene.net

25. No relations between views / tables No coupling between screens in the UI No foreign keys between tables in the persistent view model

26. Data duplication in views & tables The same information can be shown on different screens in the UI The same information can be stored in different tables in the persistent view model Tables contain a column for every piece of information shown in the UI Avoid calculations when doing queries Have the data calculated ahead of time

27. Deployment and Security Deploy the persistent view model DB to the web tier (only SELECT is permitted) Don’t have to go through the firewall – faster Role-based security Different screens for different roles go to different tables – SELECT permissions per role Just as secure as in-memory caches If not more so

28. Use for preliminary validation Before going to submit data, check if it already exists in the persistent view model Uniqueness Can expose to user (Yahoo user signup) Related Entity Existence Address validation – existence of street name Results in less commands being rejected

29. Commands – accepting user input

30. Can we fully trust users decisions?

31. Validation and Business Rules Validation: Is the input potentially good? Structured correctly? Ranges, lengths, etc Rules: Should we do this? Based on the current system state What the user saw is irrelevant

32. Command Processing Layers DB

33. Transaction Command Processing Tiers Get current state Command WS Input DB Persist Validation Validation Rules

34. Should we do what the user asks?

35. User Interface Design

36. Traditional User Interfaces Orders Save Cancel

38. Capturing user intent Why is it important? Differentiating between: Correcting a mistyped shipping address The user moved – reroute shipments underway Sometimes users accidentally modify fields when tabbing between columns

39. Reservation systems

40. Reservation systems

41. Not capturing user intent In a traditional UI – what we have is the checkbox Why do users select multiple seats? Because they’re reserving for a family / friends But then, concurrency happens Somebody else got in first on one of the seats Try to find a block of seats somewhere else

42. Capturing user intent Group reservation: Small group – sitting together Large group – several small groups Enter number of people Enter preferred seat type – indicates cost System emails back when reservation can be filled Include waiting list functionality

43. Usability benefits More users get what they want with less clicks

44. Scalability benefits Thousands of seats, hundreds of thousands of requests No need to show actual status

45. Revisiting the command

46. What’s a good command? The kind you can reply with: “Thank you. Your confirmation email will arrive shortly” Inherently asynchronous Not really related to an entity

47. Eg. Posting a comment to a blog After the browser submits the comment, immediately shows it on the page using AJAX Why wait for a response from the server? It’s not like the user’s going to call their friends and say “hey, look at the comment I just posted” And even if they did, by then it probably would have already been processed by the server

48. Eg. Withdrawing cash from an ATM Before the ATM sends the command: Using the account information retrieved Account type, Max single withdrawal, Max daily withdrawal Decides to send the command (or not) If so, dispenses cash without waiting for a response Yes – really. Exposed to race conditions Cheaper for the bank to let them through And you pay ruinous interest in those cases

49. Queries not only for views Used to decide if commands should be sent Yes – this is business logic. Get over it Client-side controllers are supposed to do logic May require additional data

50. Domain Models

51. What aren’t they for? Validation Commands are validated before the domain model is called Queries Entity relationships for reading are unnecessary

52. What are they for? In addition to doing what the command said, doing other things as well Eg. When a new order is submitted, if the customer has ordered more than X in the past, give them a discount

53. Only persist what they need The domain model isn’t responsible for persisting all data only what it needs for its purposes The rest of the world is using the data in the query store anyway

54. Putting it all together

55. For better scalability, add pub/sub Data from input immediately overlaid on queries Queries View Model UI Queries Commands Publish WS Input Validation Validation Rules Cache Updater DB

56. Summary

57. Summary Keep queries simple – 2-Tier if possible No data transfer objects Have commands reflect user intent Adjust UI design to capture intent Get the benefits of asynchronous programming Simple validation, focused business rules

58. Thank you Udi Dahan – The Software Simplist Enterprise Development Expert & SOA Specialist www.UdiDahan.com email@UdiDahan.com