CQRS - Pittsburgh ALT.NET

1. Command-QueryResponsibility Separation (CQRS) Chris Geihsler

2. Introduction About me Developing in .NET for 7 years Introduced to ALT.NET via Jeremy Miller’s blog Recently attended UdiDahan’s SOA course I’m not an expert on CQRS You won’t see much code

3. Goals Introduce and discuss the information Identify strengths and weakness of the architecture Post any unanswered questions to the DDD discussion group

5. Performance

6. One model for

7. Reads

8. Writes

9. Searches

10. Reporting?Business Logic DAL Database

11. Is there a better way? Reads and writes are different. Reads happen often and need to be fast Writes need to be transactional Architecture should reflect these differences. Separate read and write responsibilities.

12. Reads (Queries) Create a model used only for reads Structure data around the UI One “table” per view Persistent View Model Inherently denormalized Read-only Data retrieval is easy and fast SELECT * FROM CustomerSummaryView Scales cheaply

13. The world is not read-only The system needs to capture change Real world events User decisions Expose commands that change system state One-way Imperative Validated for correctness

15. Keep it simple!

16. Probably don’t need a domain model

17. Create a data store that persists system state

18. Transactional

19. Write-Only (mostly)

21. No need for public getters or setters

22. Example:public voidHandle(MakeCustomerPreferredCommandcmd) { using(ISessions = ORM.OpenSession()) using(ITransactiontx = s.BeginTransaction()) { varc= s.Get<Customer>(cmd.CustomerId); c.MakePreferred(); tx.Commit(); } }

23. Closing the loop Command side publishes events Contain details about state change Past tense Query side subscribes to those events Updates persistent view models Consistency Immediate Eventual

24. Event example public class CustomerWasMadePreferredEvent { public intCustomerId { get; set; } public decimal DiscountPercent { get; set; } } public void Handle(CustomerWasMadePreferredEventevt) { //UPDATE CustomerDetailsView WHERE CustomerID = evt.CustomerID //UPDATE CustomerSummaryViewWHERE CustomerID = evt.CustomerID //etc. }

25. Questions?

26. Further Implications Few relationships in either model Why use a RDBMS? Event sourcing Scalability via messaging patterns Events have other uses 3rd Party Integration Real-time updates of clients CRUD based UI vs. Task based UI

27. More Information Yahoo DDD discussion group http://tech.groups.yahoo.com/group/domaindrivendesign/ UdiDahan’s website www.udidahan.com Greg Young Mark Nijhof http://elegantcode.com/author/mark-nijhof/