This document discusses how CQRS (Command Query Responsibility Segregation) can be combined with the Actor Model and Akka.NET to build distributed, reactive applications. It provides background on CQRS and the Actor Model, and explains how actors can be used to implement CQRS handlers. Key elements of CQRS like separate command and query paths and message-based communication are still present. The document also discusses how to structure the application into services that encapsulate CQRS handlers for scalability. It concludes that CQRS is still relevant when applied to reactive systems using frameworks like Akka.NET that support the Actor Model.
2. ABOUT ME
5-Time .NET (Visual C#) MVP (April 2011)
Sr. Solutions Architect at Confluence
One of the organizers for Pittsburgh TechFest (http://pghtechfest.com)
Organizer of Pittsburgh Reactive Dev Group (http://meetup.com/reactive)
Past President of Pittsburgh .NET Users Group
Twitter - @DavidHoerster
Blog – http://blog.agileways.com
Email – david@agileways.com
3. GOALS
What are the principles behind CQRS
How can I apply them in my current development
How Akka(.NET) shares much in common wth CQRS
How CQRS + Akka(.NET) can help with building distributed, reactive
applications
7. CQRS BACKGROUND
Command Query Responsibility Segregation
Coined by Greg Young
Heavily influenced by Domain Driven Design (DDD)
Evolution of Meyer’s CQS (Command Query Separation)
Separation of writes (command) and reads (query)
CQS is more at the unit level
CQRS is at a higher level bounded context / service
8. WHAT IS CQRS?
Simply: separate paths for reads and writes
Communicate via messages
Commands and Events
“CreateOrder” and “OrderCreated”
Reads are against a thin read model (preferably optimized)
11. CQRS EXTENDED
Can move from direct references to queued
Decouples handlers
Increased isolation of areas
Leads to single message causing several changes
Raising of events and subscriptions to events
15. BENEFITS
Message Based
Segregation of Responsibilities – Separate Paths
Smaller, simpler classes
Albeit more classes
Focused Approach to Domain
Move away from anemic domain models
16. CQRS PRINCIPLES
Separate Paths for Command and Queries
Message-Based
Async Friendly
Thin read layer
Don’t fear lots of small classes
20. "CQRS IS HARD"
Misunderstandings
Has to be async
Has to have queueing
Need a separate read model
Need to have Event Sourcing
Perceived as overly prescriptive, but little prescription
Confusing
Command Handler vs. Event Handler vs. Domain
Command vs. Event
21. HAS CQRS “FAILED”?
Focus on CQRS as architecture over
principles
Search for prescriptive guidance
Infrastructure/Implementation debates
Should domains have getters??
“…there are times a getter can be pragmatic. The trick is
learning where to use them.” – Greg Young (DDD/CQRS
Group)
“This list has its heads up its own
[butts] about infrastructure. What
business problems are you working on?”
-- Greg Young (DDD/CQRS Group)
24. BUT ISN’T CQRS…?
Message Driven
Responsive Read Model
Isolated Handlers
Async Friendly
Group Handlers into Clusterable Groups
NoSQL Friendly (Flattened Read Models)
27. CQRS & THE REACTIVE MANIFESTO
Message Based
Core of CQRS
Responsive
Commands are ack/nack
Queries are (can be) against an optimized read model
Resillient
Not core to CQRS Implementation
Elastic
Not core to CQRS Implementation
28. SIDE NOTE: REACTIVE VS.
PROACTIVE
Isn’t proactive a good thing?
A system taking upon itself to
check state is proactive
It’s doing too much
A reactive system reacts to
events that occur
It’s doing just the right amount
29. SIDE NOTE: REACTIVE VS.
PROACTIVE
Isn’t proactive a good thing?
A system taking upon itself to
check state is proactive
It’s doing too much
A reactive system reacts to
events that occur
It’s doing just the right amount
System
EvtEvt
System
EvtEvt
Proactive
Reactive
30. CQRS + REACTIVE
Resillient and Elastic core to
Reactive
CQRS’ core is Message-Based
and Responsive
Combining the two is powerful
31. ACTOR MODEL
CQRS lacks prescriptive guidance
Actor Model provides a message-based pattern
Provides prescriptive guidance
Makes for more generalized implementation
Actor Model is driving more reactive-based development
32. ACTOR MODEL
Actor Model is a system made of small units of concurrent
computation
Formulated in the early 70’s
Each unit is an actor
Communicates to each other via messages
Actors can have children, which they can supervise
33. WHAT IS AN ACTOR?
Lightweight class that encapsulates state and behavior
State can be persisted (Akka.Persistence)
Behavior can be switched (Become/Unbecome)
Has a mailbox to receive messages
Ordered delivery by default
Queue
Can create child actors
Has a supervisory strategy for child actors
How to handle misbehaving children
Are always thread safe
Have a lifecycle
Started, stopped, restarted
35. AKKA: RESILIENCY
Actors supervise their children
When they misbehave, they are notified
Can punish (fail) all children, or tell the misbehaving on to try again
Protects rest of the system
36. AKKA.NET
Akka.NET is an open source framework
Actor Model for .NET
Port of Akka (for JVM/Scala)
http://getakka.net
NuGet – searching for “akka.net”, shows up low in the list
37. STARTING WITH AKKA.NET
Akka.NET is a hierarchical system
Root of the system is ActorSystem
Expensive to instantiate – create and hold!
ActorSystem can then be used to create Actors
38. CREATING AN ACTOR
An Actor has a unique address
Can be accessed/communicated to like a URI
Call ActorOf off ActorSystem, provide it a name
URI (actor path) is created hierarchically
Actor Path = akka://myName/user/announcer
39. SENDING A MESSAGE
Messages are basis of actor communication
Should be IMMUTABLE!!!
“Tell” an actor a message
Async call
Immutable!!
40. RECEIVING A MESSAGE
Create your Actor
Derive from ReceiveActor
In constructor, register your
message subscriptions
Looks similar to a CQRS
Handler
41. RECEIVING A MESSAGE
Each actor has a mailbox
Messages are received in the actor’s mailbox (queue)
Actor is notified that there’s a message
It receives the message
Takes it out of the mailbox
Next one is queued up
Ordered delivery by default
Other mailboxes (like Priority) that are out-of-order
Actor
Mailbox
Msg
43. ELEMENTS OF CQRS IN ACTOR
MODEL
Message-based
Potentially async
Focused code
Actor System is your Command Side
44. CQRS + ACTORS
Combining the principles of CQRS and the patterns of the Actor
Model
Message-based communication with concurrent processing
45. CQRS + ACTORS: MESSAGES
Messages in an Actor System include both Commands and Events
Still encapsulate intent
Still should still contain information necessary to process/handle
command or event
Basically, no big change here
47. CQRS + ACTORS: HANDLERS
Handlers begin to encapsulate your
Actor System
Generally a single Actor System per
handler
Have several actors at top level of
hierarchy to handle initial messages
Domain can be injected into the
Actor System via Create()
Handler
Client
Queue
Persistence
Other Handler
Direct call or via
queue
50. CQRS + ACTORS: HANDLERS
Handlers act as the entry point
Web API
Service subscribed to queue
CQRS IHandle<T> for those messages “exposed”
Actor System is called by the CQRS Handler
Actor System has many other “internal” actors
51. CQRS + ACTORS: SERVICES
Word Counter Handler
super
Count Write Stats
A B G H Y Z
53. Word Counter
Handler
CQRS + ACTORS: SERVICES
super
Count
A B
Word Writer
Handler
super
Write
G H
Word Stats
Handler
super
Stats
Y Z
Message Bus
54. CQRS + ACTORS + SERVICES
Service A Service B Service C
Message Bus
DW / DL /
Read Model
Cmds / Events Cmds / Events
API Gateway SvcCommands Queries
RM RMRM
Queries (?)
55. Service A
Service A
Service A
CQRS + ACTORS + SERVICES +
CLUSTER (AKKA.CLUSTER)
Service A Service B Service C
Message Bus
DW / DL /
Read Model
Cmds / Events Cmds / Events
API Gateway SvcCommands Queries
RM RMRM
Queries (?)
56. CQRS + ACTORS + SERVICES
Actors act as the workers for your handlers
Services encapsulate handler into a bounded context
CQRS is the messaging and communication pattern within system
Using these three helps build killer reactive applications
57. CONCLUSIONS
CQRS is not dead
Key principles of messaging, separate paths and responsibility
segregation
Apply CQRS to Reactive systems (e.g. an Akka.NET system) for best of
both
Encapsulate handlers into services for scalability and reliability