CQRS in an hour or so 1

Who is jdn? Me, aka John Nuechterlein Blog: Operations Manager – Developer – Architect - Raging Douchebag eCom then Finance hopefully ecom again background Ph.D. in Philosophy (University of Miami at the age of 25) – HI JEREMY!!!!!!! 2

Sources Greg Young – 009/08/13/command-query-separation.aspx Udi Dahan – cqrs/ Mark Nijhof – young/ 3

CQRS CQRS = “Command Query Responsibility Segregation” Huh? A design – pattern -architecture – Framework – Principle – Something Makes stuff better Huh? 4

CQS Defined Bertrand Meyer (via Wikipedia) “Command Query Separation” – “every method should either be a command that performs an action, or a query that returns data to the caller, but not both. In other words, asking a question should not change the answer.”method 5

CQRS defined Meyer: Separate command methods that change state from query methods that read state. Greg Young: Separate command messages that change state from query messages that read state. Can have significant architectural implications 6

Nihjof #1 7

Nihjof #2 8

Nihjof Categories 1 – Queries 2 – Commands 3 – Internal Events 4 – External Events 9

UDI #1 10

Queries ‘Reporting’ – Misleading description (Greg’s fault), but makes some sense Simple Query Layer – Simple views or sprocs or selects from denormalized tables Simple DTOs, no mapping needed – Don’t go through the Domain Model, as it pollutes it – ViewModel per query perhaps – Why should the data come across 5 layers through 3 model transformations to populate a screen? (Udi) ‘Traditional Reporting’ – Can (almost always will) have its own Model as well (and perhaps/probably its own data source) Synchronous, no messaging needed Eventual Consistency (more later) 11

Queries No mapping code, don’t even bother getting a domain object at all, e.g.: public class ModelDetailBrickDTOMapper : IMapper { public ModelDetailBrickDTO Map(Model m) { return new ModelDetailBrickDTO(m.ID, m.Name, m.Description, m.Details, m.ShippingMessage, m.GetPrice("Current"), m.GetPrice("MSRP"), m.Sizes, m.Images, DisplayProductBrick.GetRelatedDisplayProductBricksByModel(m)) ; } 12

Queries Data store – Cache it (it’s already stale) – Why not on web-tier? – Why relational? Horizontal scalability – If you cache, add a new server to handle it 13

Commands Commands capture intent, DTOs don’t – CustomerDTO vs CustomerChangedAddressCommand Part of the ‘Ubiquitous’ Language Handler per command Can be validated outside of domain entities This is why no getters/setters on domain entities, their state is updated by processing commands according to the rules of the business This is why domain entities are never invalid, commands that would produce invalid state are rejected 14

Commands Separate Data Modification – Make preferred – Change address – Delinquent payment event example Comes in 1 ms after make preferred event What to do? – A generic DTO could do these things, of course, but after the fact, how do you know what actually happened? UI Implications – Excel-like screens don’t work – Commands require specific intent 15

Commands Commands can be queued – Split into separate queues Scale where needed Commands don’t have to be handled by the domain 16

Internal Events Triggered by commands Can be persisted – Could be RDBMS, ODBMS, Document DB, etc. – Event sourcing (big topic, punting) Can be replayed – Production support benefit Snapshots can also be created & persisted – Don’t delete original events Domain can accept command or reject it – Raise event either way 17

Internal Events Write-only – “Accountants don’t use erasers” Compensating Actions/Events – Instead of rolling back a transaction, you compensate for some failure Automatic audit log – You have all the events that happened No more ‘impedence mismatch’ – You are persisting events, not rows Data mining – Like I said, you have all the events that happened 18

External Events Publishing – Typically, message bus – Could use views or ETL to process in a ‘simpler’ architecture Data stores can subscribe Only process when a read request comes in (GY) 19

External Events Publishing external events and persisting internal events done in a transaction Eventual Consistency – Latency is almost always okay – Question is, how much? – Availability trumps correctness – Acting on incomplete data is normal Event handler per view model, perhaps 20

Why not CQRS? It’s new, it’s different, I’m stupid Multiple data stores Operational Complexity Losing ACID/Transactions is scary Lots of Commands and Events and Handlers and Lions and Tigers and Bears oh my! to Code 21

Questions? 22