CQRS 2.0 and Akka.NET for Building Reactive Apps
•Download as PPTX, PDF•
17 likes•6,317 views
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.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to CQRS 2.0 and Akka.NET for Building Reactive Apps
Similar to CQRS 2.0 and Akka.NET for Building Reactive Apps (20)
More from David Hoerster
More from David Hoerster (9)
Recently uploaded
Recently uploaded (20)
CQRS 2.0 and Akka.NET for Building Reactive Apps
- 1. CQRS 2.0 David Hoerster
- 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
- 13. CQRS HANDLER
- 14. CQRS HANDLER
- 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
- 17. A CALL
- 18. Is CQRS Dead?
- 19. <rant>
- 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)
- 22. </rant>
- 23. POPULAR ARCHITECTURE TOPICS Microservices Event driven Distributed computing NoSQL Async
- 24. BUT ISN’T CQRS…? Message Driven Responsive Read Model Isolated Handlers Async Friendly Group Handlers into Clusterable Groups NoSQL Friendly (Flattened Read Models)
- 25. CQRS CAN HELP DRIVE REACTIVE APPS
- 26. CQRS EVOLVED
- 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
- 46. CQRS + ACTORS: MESSAGES
- 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
- 48. CQRS + ACTORS: HANDLERS
- 49. CQRS + ACTORS: HANDLERS
- 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
- 52. DEMO: HELLO CQRS + AKKA.NET
- 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