cqrs evolved - cqrs + akka.net

CQRS 2.0 David Hoerster

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

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

PREFACE:FIRST CONTACT

Click icon to add picture

SOME CQRS BACKGROUND

Click icon to add picture

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

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)

CQRS VISUALIZED: BASIC

Client

Backend

Commands Queries

CQRS VISUALIZED

Controller

Handler

Domain

Persistence / Read Model

Read Layer

CommandSide

QuerySide

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

CQRSVISUALIZED

Controller

Handler

Domain

Persistence

Read Layer

Handler

Com

man

d / E

vent

To

pics

Read Model

CommandSide

QuerySide

CQRS HANDLER

CQRS HANDLER

BENEFITS Message Based

Segregation of Responsibilities – Separate Paths

Smaller, simpler classes Albeit more classes

Focused Approach to Domain Move away from anemic domain models

CQRS PRINCIPLES Separate Paths for Command and Queries

Message-Based

Async Friendly

Thin read layer

Don’t fear lots of small classes

A CALL

Click icon to add picture

Is CQRS Dead?

<rant>

"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

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)

</rant>

POPULAR ARCHITECTURE TOPICS Microservices

Event driven

Distributed computing

NoSQL

Async

BUT ISN’T CQRS…?

Message Driven

Responsive Read Model

Isolated Handlers Async Friendly

Group Handlers into Clusterable Groups

NoSQL Friendly (Flattened Read Models)

CQRS CAN HELP DRIVE REACTIVE APPS

CQRS EVOLVED

Click icon to add picture

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

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

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

CQRS + REACTIVE Resillient and Elastic core to Reactive

CQRS’ core is Message-Based and Responsive

Combining the two is powerful

ACTOR MODELCQRS 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

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

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

ACTOR HIERARCHYbaseball

gameCoordinator

gameInfo-x

gameInfo-y

playerSupervisor

batter-abatter-bbatter-c

c-01 c-11 c-32

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

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

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

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

SENDING A MESSAGE Messages are basis of actor communication Should be IMMUTABLE!!!

“Tell” an actor a message Async call

Immutable!!

RECEIVING A MESSAGE Create your Actor

Derive from ReceiveActor

In constructor, register your message subscriptions

Looks similar to a CQRS Handler

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

Mai

lbox

Msg

DEMO: HELLO AKKA.NET

Click icon to add picture

ELEMENTS OF CQRS IN ACTOR MODEL Message-based

Potentially async

Focused code

Actor System is your Command Side

CQRS + ACTORS Combining the principles of CQRS and the patterns of the Actor Model

Message-based communication with concurrent processing

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

CQRS + ACTORS: MESSAGES

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

QueuePersistenceOther Handler

Direct call or via queue

CQRS + ACTORS: HANDLERS

CQRS + ACTORS: HANDLERS

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

CQRS + ACTORS: SERVICESWord Counter Handler

super

Count Write Stats

A B G H Y Z

DEMO: HELLO CQRS + AKKA.NET

Click icon to add picture

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

CQRS + ACTORS + SERVICES

Service A Service B Service C

Message Bus

DW / DL / Read Model

Cmds / Events Cmds / Events

API Gateway SvcCommands Queries

RM RMRMQueries (?)

Service AService AService 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 RMRMQueries (?)

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

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