This document discusses Command Query Responsibility Segregation (CQRS), which separates commands and queries. Commands change state while queries do not. This improves scalability by allowing independent processing of reads and writes. The document also discusses using CQRS with event sourcing and Akka persistence, where commands generate events that are persisted and used to recover state. Queries are handled separately from the domain model using views rebuilt from stored events.

1. (c) 2015-16, No reproduction without permission
CQRS
Vikas Hazrati
Knoldus Software

2. (c) 2015-16, No reproduction without permission
What
Command Query
Responsibility Segregation

3. (c) 2015-16, No reproduction without permission
What
Command Query
Responsibility Segregation
Not an
architecture, just
a pattern

4. (c) 2015-16, No reproduction without permission
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

5. (c) 2015-16, No reproduction without permission
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.

6. (c) 2015-16, No reproduction without permission
Real world
●
Methods which return something are mostly
queries – specialized reporting needs
●
Methods which return unit are commands –
domain with all the behavior

7. (c) 2015-16, No reproduction without permission
Why?
●
Helps to scale read and writes independently
●
Optimise the reads and writes separately for
performance tuning
●
Split the teams for larger projects

8. (c) 2015-16, No reproduction without permission

9. (c) 2015-16, No reproduction without permission
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

10. (c) 2015-16, No reproduction without permission

11. (c) 2015-16, No reproduction without permission
Command Side
●
Created by the client app and sent to the
domain layer
●
Messages that instruct the entity to perform
some action

12. (c) 2015-16, No reproduction without permission

13. (c) 2015-16, No reproduction without permission
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

14. (c) 2015-16, No reproduction without permission

15. (c) 2015-16, No reproduction without permission
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

16. (c) 2015-16, No reproduction without permission
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?

17. (c) 2015-16, No reproduction without permission
Example
CustomerService
●
void MakeCustomerPreferred(CustomerId)
●
Customer GetCustomer(CustomerId)
●
CustomerSet GetCustomersWithName(Name)
●
CustomerSet GetPreferredCustomers()
●
void ChangeCustomerLocale(CustomerId, NewLocale)
●
void CreateCustomer(Customer)
●
void EditCustomerDetails(CustomerDetails)

18. (c) 2015-16, No reproduction without permission
Example
CustomerService
●
void MakeCustomerPreferred(CustomerId)
●
Customer GetCustomer(CustomerId)
●
CustomerSet GetCustomersWithName(Name)
●
CustomerSet GetPreferredCustomers()
●
void ChangeCustomerLocale(CustomerId, NewLocale)
●
void CreateCustomer(Customer)
●
void EditCustomerDetails(CustomerDetails)
What would you separate
out?

19. (c) 2015-16, No reproduction without permission
Example
CustomerWriteService
●
void MakeCustomerPreferred(CustomerId)
●
void ChangeCustomerLocale(CustomerId, NewLocale)
●
void CreateCustomer(Customer)
●
void EditCustomerDetails(CustomerDetails)
CustomerReadService
●
Customer GetCustomer(CustomerId)
●
CustomerSet GetCustomersWithName(Name)
●
CustomerSet GetPreferredCustomers()

20. (c) 2015-16, No reproduction without permission
Tying it up with Event Sourcing
and Akka

21. (c) 2015-16, No reproduction without permission
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.

22. (c) 2015-16, No reproduction without permission
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

23. (c) 2015-16, No reproduction without permission

24. (c) 2015-16, No reproduction without permission
Akka Persistence
●
Command path implemented using
PersistentActor
●
Query path implemented using
PersistentView

25. (c) 2015-16, No reproduction without permission
Example
●
Create an Auction
●
Place a did
●
Query for the current winning bid
●
Query for the bid history

26. (c) 2015-16, No reproduction without permission
REST Endpoints
Or
UI
Command
Handler
Ack/nack
Domain
DB
Event
CacheQuery
Handler

27. (c) 2015-16, No reproduction without permission
Command
BidProcessor.scala. This is a PersistentActor

28. (c) 2015-16, No reproduction without permission
Query

29. (c) 2015-16, No reproduction without permission

30. (c) 2015-16, No reproduction without permission

31. (c) 2015-16, No reproduction without permission
Resources
Full credits to the following and more resources
for helping us with the understanding! Thank
you!
●
http://martinfowler.com/bliki/CQRS.html
●
http://udidahan.com/2009/12/09/clarified-cqr
s/
●
http://www.cqrsinfo.com/