Command Query Responsibility Segregation

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

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

History

Paper ruled the world

And then came the computer

And with it data entry

And efficient UIs were designed for it

Source of truth

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

But the UI lingers to this day

No change to architecture either

Distributed Systems Architecture

Common Distributed Architecture
DB

Let’s deal with the obvious…

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

So why go through all the layers?
Cache
DB

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

What was the point of all this again?

Queries – showing data to the user

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

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

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)

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

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

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

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

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

Commands – accepting user input

Can we fully trust users decisions?

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

Command Processing Layers
DB

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

Should we do what the user asks?

User Interface Design

Traditional User Interfaces
Orders
Save
Cancel

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

Reservation systems

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

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

Usability benefits
More users get what they want with less clicks

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

Revisiting the command

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

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

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

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

Domain Models

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

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

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

Putting it all together

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

Summary

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

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

http://skillsmatter.com	10105
http://www.codinginlondon.com	60
http://www.slideshare.net	36
http://golios.blogspot.com	8
http://chandermani.blogspot.in	6
http://translate.googleusercontent.com	3
http://static.slidesharecdn.com	3
http://chandermani.blogspot.com	3
http://85.92.73.37	2
http://us-w1.rockmelt.com	2
http://webcache.googleusercontent.com	1
http://www.chandermani.blogspot.com	1
http://chandermani.blogspot.kr	1

Command Query Responsibility Segregation

by Skills Matter

Accessibility

Categories

Upload Details

Usage Rights

13 Embeds 10,231

Statistics