A session on the CQRS pattern (Command Query Responsibility Separation) with C# code samples, and a discussion of what it means for your architecture and when and why you should use it. First presented at the Sydney Alt.Net group in June 2016.

1. CQRS
Separating your peas from your potatoes
http://richard-banks.org, @rbanks54

2. Command
Query
Responsibility
Separation

3. Commands
– update state, no return value
Queries
– read state, return data
- no side effects

4. Example: HTTP Verbs

5. Queries
---
GET
HEAD
OPTIONS
TRACE

6. Commands
---
PUT
POST
PATCH
DELETE

7. By the way,
is it CQS or CQRS?

8. CQS = Command Query Separation
In one class, have separate methods for
changing and reading state

9. public class UserAccount
{
//...
public bool IsActive { get; private set; }
public void Activate()
{
IsActive = true;
}
public void DeActivate()
{
IsActive = false;
}
}
Query
Command
Command

10. CQRS
Have separate classes for changing and
reading state

11. public class UserAccount
{
//Only change state of the object via methods within the class
//State changing methods are marked internal
public bool IsActive { get; private set; }
internal void Activate()
{
IsActive = true;
}
internal void DeActivate()
{
IsActive = false;
}
}

12. public class AccountQueryService
{
IQueryable<UserAccount> db;
public AccountQueryService(IQueryable<UserAccount> db)
{
this.db = db;
}
public UserAccount FindByName(string accountName)
{
return db.Where(a => a.Name.Equals(accountName)).Single();
}
public IEnumerable<UserAccount> ActiveAccounts()
{
return db.All(a => a.IsActive);
}
}
Anti Pattern in use for
simplicity of sample code
Should return just the data
needed, not a domain object

13. public class AccountCommandHandler
{
AccountQueryService view; ILogger logger;
public AccountCommandHandler(AccountQueryService view, ILogger logger)
{
this.view = view; this.logger = logger;
}
public void ActivateAccount(string accountName)
{
try
{
var account = view.FindByName(accountName);
account.Activate();
}
catch { logger.Log("oops!"); throw; }
logger.Log("Account activated...");
}
}

14. Possible first reaction?
Whoa! Lots more code!! 
Yes. Though it’s more expressive and
intentional too.

15. Question:
Where should persistence calls occur?

16. MVC/API Controller?
In the UserAccount class?
Elsewhere?

17. public class AccountCommandHandler
{
//…
public void ActivateAccount(string accountName)
{
try
{
var account = view.FindByName(accountName);
account.Activate();
db.Save(account);
}
catch
{
logger.Log("oops!");
throw;
}
logger.Log("Account activated...");
}
}

18. Can we use query objects instead of
query services? Sure!

19. public class ActiveAccountsQuery : IQuery
{
IQueryable<UserAccount> db;
public ActiveAccountsQuery(IQueryable<UserAccount> db)
{
this.db = db;
}
public IEnumerable<UserAccount> Execute()
{
return db.All(a => a.IsActive).ToList();
}
}

20. Question:
Should we drop the .Activate() and
.DeActivate() methods from the
UserAccount class?

21. public class UserAccount
{
//Hello, anaemic domain model!
public bool IsActive { get; internal set; }
}

22. Is an Anaemic Domain Model OK?
Consultant answer: It Depends!

23. Consider:
Are we building a CRUD app?
What happens when business rules
change?

24. public class UserAccount
{
private string EmailValidated { get; private set; }
public bool IsActive { get; private set; }
internal void Activate()
{
if (!EmailValidated)
throw new ApplicationException("email is not yet verified");
IsActive = true;
}
internal void DeActivate()
{
IsActive = false;
}
}
Behaviour change
implemented in the
domain entity
No changes needed
anywhere else

25. Design Principles

26. Separation of Concerns,
Single Responsibility

27. Domain Classes are responsible for
their behaviours
(Avoid the anaemic domain model)

28. Command Handlers are responsible
for coordinating state changes
(use repositories to persist those changes)

29. Query Objects are responsible for
retrieving data in a shape the
consumer wants.
(Completely avoids calling the domain)

30. What’s this mean for my
architecture?

31. UI Application Domain Data
Commands
UI Application Data
Queries

32. Command Services/Handlers
UI
Commands
Domain Model
Repositories
DatabaseQuery Store
Query Service
Data Access Layer
Projections
Queries
Business Actions
Changes
Query
Store
No O/R
conversions
Describes
the user’s
intent
Optimized
for querying
Synchronous or
asynchronous
updates
Can simply be
denormalised tables
in the main DB

33. Commands

34. A command should describe
a single user intention
against a single domain entity
e.g. OpenAccount,
ResetAccountPassword
DisableAccount

35. Thinking about commands and
objects leads us towards…
Domain Driven Design

36. High level DDD Concepts:
Entity: discrete lifecycle and identity
Value Object: no lifecycle, identified only by attribute values.
Aggregate: one or more entities and value objects,
clustered together as a coherent whole.
Agg. Root: single entity that controls access to other
objects in the aggregate
Context: setting in which a word has specific meaning
(e.g ‘account’)

37. Define modules in your app based on
your Domain Contexts.

38. Commands act on the
Aggregate Roots in your Context

39. Queries

40. Queries just need to get data.
So why go via the domain model?

41. UI Application Domain Data
Commands
UI Application Data
Queries

42. Why not de-normalise our data
to optimise for reads?
Why not store it in a different
database?

43. Question:
If we split the storage of our domain data and our
denormalised data…
How do we keep things in sync?

44. We could keep the data on the same
DB server…
…and use transactions/triggers to
update multiple tables at once.

45. Or we could think about eventual
consistency.
(Note: This is not required for CQRS)

46. When a Domain Entity changes state,
raise a Domain Event to describe
what happened.

47. These Domain Events can be treated
as messages and published on a
message bus

48. Event Handlers subscribe to the
events and update denormalised
views of data.
Makes transactions simpler.
Must consider the impact of Eventual Consistency
on our users.

49. Publishing Domain Events can lead to
thinking about Event Sourcing.
Note: Event Sourcing is NOT
REQUIRED for CQRS

50. Commands and Queries will likely
lead to a Task based UI approach.

51. What’s the catch?

52. CQRS means you’ll need to think
about design and your domain model.

53. It’s not needed for CRUDdy, “forms
over data” applications

54. Commands are not “fire and forget”.
You need to think about concurrency
and exception handling.

55. You need to decide how to
denormalize data.
Eventual consistency is not simple.

56. It’s easy to fall back into old habits

57. It’s hard to add to a legacy system

58. It’s complexity you might not need.
Apply the YAGNI rule.

59. So Why Use It Then?

60. You have a complex domain model

61. You have a scalability or performance
problem

62. You’re building a task based UI

63. You have a collaborative domain
model
Think, concurrent partial updates of the same
entity by multiple people

64. OK. We’re Done!
Want some references?

65. MS Patterns & Practices, CQRS Journey: http://cqrsjourney.github.io/
Greg Youngs CRQS and Event Sourcing demo app: https://github.com/gregoryyoung/m-r
NCQRS Framework: https://github.com/pjvds/ncqrs
CQRS FAQ: http://www.cqrs.nu/Faq/command-query-responsibility-segregation
Effective Aggregate Design: http://dddcommunity.org/library/vernon_2011/
CQRS Myths: https://lostechies.com/jimmybogard/2012/08/22/busting-some-cqrs-myths/
Task based UIs: https://cqrs.wordpress.com/documents/task-based-ui/