Scalable Architecture for the Cloud
CQRS AND WINDOWS AZURE

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?

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

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

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

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

3-Tier Architecture
DB
Domain
UI

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

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

CQRS Architecture
DB
DOMAIN
UI

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

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!

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

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

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

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

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

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

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

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!

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

Show me some code!

A special bonus pattern!
EVENT SOURCING

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

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

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

Questions?