CQRS and what it means for your architecture

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

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

Command
Query
Responsibility
Separation

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

Example: HTTP Verbs

Queries
---
GET
HEAD
OPTIONS
TRACE

Commands
---
PUT
POST
PATCH
DELETE

By the way,
is it CQS or CQRS?

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

public class UserAccount
{
//...
public bool IsActive { get; private set; }
public void Activate()
{
IsActive = true;
}
pu...

CQRS
Have separate classes for changing and
reading state

public class UserAccount
{
//Only change state of the object via methods within the class
//State changing methods are mar...

public class AccountQueryService
{
IQueryable<UserAccount> db;
public AccountQueryService(IQueryable<UserAccount> db)
{
th...

public class AccountCommandHandler
{
AccountQueryService view; ILogger logger;
public AccountCommandHandler(AccountQuerySe...

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

Question:
Where should persistence calls occur?

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

public class AccountCommandHandler
{
//…
public void ActivateAccount(string accountName)
{
try
{
var account = view.FindBy...

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

public class ActiveAccountsQuery : IQuery
{
IQueryable<UserAccount> db;
public ActiveAccountsQuery(IQueryable<UserAccount>...

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

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

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

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

public class UserAccount
{
private string EmailValidated { get; private set; }
public bool IsActive { get; private set; }
...

Design Principles

Separation of Concerns,
Single Responsibility

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

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

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

What’s this mean for my
architecture?

UI Application Domain Data
Commands
UI Application Data
Queries

Command Services/Handlers
UI
Commands
Domain Model
Repositories
DatabaseQuery Store
Query Service
Data Access Layer
Projec...

Commands

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

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

High level DDD Concepts:
Entity: discrete lifecycle and identity
Value Object: no lifecycle, identified only by attribute ...

Define modules in your app based on
your Domain Contexts.

Commands act on the
Aggregate Roots in your Context

Queries

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

UI Application Domain Data
Commands
UI Application Data
Queries

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

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

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

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

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

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

Event Handlers subscribe to the
events and update denormalised
views of data.
Makes transactions simpler.
Must consider th...

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

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

What’s the catch?

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

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

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

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

It’s easy to fall back into old habits

It’s hard to add to a legacy system

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

So Why Use It Then?

You have a complex domain model

You have a scalability or performance
problem

You’re building a task based UI

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

OK. We’re Done!
Want some references?

MS Patterns & Practices, CQRS Journey: http://cqrsjourney.github.io/
Greg Youngs CRQS and Event Sourcing demo app: https:/...

Share Slideshare

LinkedIn
Facebook
Twitter

Embed

Size (px)

Show related Slideshows at end

WordPress Shortcode

Link

Share
Email

Architecting Microservices in .Net by Richard Banks 10127 views
.Net Microservices with Event Sourc... by Javier García Magna 8711 views
Microservice vs. Monolithic Archite... by Paul Mooney 91359 views
Building Microservices with .NET (s... by Binary Studio 1279 views
Building .NET Microservices by VMware Tanzu 4104 views
Domain Driven Design Experience Report by Skills Matter 1202 views

View on Slideshare

1 of 65 Ad

View on Slideshare

1 of 65 Ad