What Not an architecture, just a pattern Command Query Responsibility Segregation
Main Idea ● A method should either change state or return a result, not both ● Asking a question should not change the answer (SRP + Immutability) – No side effects
Main Idea ● Commands - change the state of an object or entire system (sometimes called as modifiers or mutators). ● Queries - return results and do not change the state of an object.
Real world ● Methods which return something are mostly queries – specialized reporting needs ● Methods which return unit are commands – domain with all the behavior
Why? ● Helps to scale read and writes independently ● Optimise the reads and writes separately for performance tuning ● Split the teams for larger projects
Query ● Methods for getting data ● DTO's which are passed to the presentation layer for presentation ● Converting domain object to data might be complex, in CQRS we get DTOs directly from underlying data store
Command Side ● Created by the client app and sent to the domain layer ● Messages that instruct the entity to perform some action
Main Drivers ● Collaboration – Multiple actors / objects would be modifying the same set of data
● Staleness – The fact that once data has been shown to the user, it might have changed by another actor hence rendering it stale
Queries on an additional datastore which can be slightly out of sync with the master but would server data in the form required by the presentation layer. The query data can be stored in any persistence mechanism right from being In memory to RDBMS
Commands need not be processed immediately, they can be queued. Consider the autonomous components to be actors where every actor is responsible for handling a group of related commands Since the domain model now does not serve queries, do we need relationship between entities on the domain model?
Event Sourcing ● Event Sourcing means that all changes to application state are stored as a sequence of events. ● This sequence of events can be used to query the current state of an object but also the history of an object. ● Event sourcing allows one to create different kinds of views, even views which one did not even think of when creating the application.
● Because all events are stored, one can query the event store to create these new views based on the data- even at a later date.
Akka Persistence ● Event Sourcing review ● Persistent actor receives a command which is first validated and if successful, event(s) are generated. ● These events are persisted and if successfully persisted, change the actor's state ● When persistent actor needs to recover, persisted events are replayed. These events cannot fail
Akka Persistence ● Command path implemented using PersistentActor ● Query path implemented using PersistentView
Example ● Create an Auction ● Place a did ● Query for the current winning bid ● Query for the bid history
Command Handler Domain DB Ack/nack REST Endpoints Or UI Event Query Cache Handler
Command BidProcessor.scala. This is a PersistentActor