This session of ArcBlock's Technical Learning Series will introduce CQRS and commanded. CQRS stands for Command Query Responsibility Segregation. At its heart is the notion that you can use a different model to update information than the model you use to read information. We will have a look into what CQRS and commanded (a framework for elixir) are and how they fit together, followed by a introduction on how to implement an application using CQRS concepts with commanded in our service. "

1. CQRS & Commended
Brought to you by Lei Zhou
1

2. THIS TALK…
• … understand the basic idea of ES/CQRS
• … know about the advantages of ES/CQRS
• … learn about the issues that come with ES
• … build app (implemented with Commanded lib)
2

3. Event Sourcing
3

4. Active Record Pattern
• A database table or view is wrapped into a class, an object instance is tied to a single
row in the table.
4

5. Event Sourcing is di erent
• Don’t save the current state of objects
• Save the events that lead to the current state
• Event: Something that happened in the past. e.g.
5

6. How does Event Sourcing work?
•
• Create an event of every state change of the object
• Persist this stream of events, preserving event order
6

7. Restoring objects 7

8. Restoring objects 8

9. Restoring objects 9

10. Restoring objects 10

11. Restoring objects 11

12. Event Sourcing
• Sn = apply(Sn-1, En)
• Sn = reduce(E, S0, apply)
• S: state, E: event
12

13. The advantages of Event Sourcing
• Complete log of every state change ever
• Traceability and debug-ability
• Very good performance characteristics
• No more mapping objections to tables
13

14. Real World Example
14

15. Event Sourcing
• git
• State: Files
• Events: Commits
15

16. Event Sourcing
• Blockchain
• State: Balance
• Events: Transaction
16

17. Event Sourcing
• Write ahead logging
• State: DB
• Events: changes (recorded in the log)
• Must be written to a stable storage before converted unto a disk
• Purpose: when the machine it is running on loses power
17

18. Questions
• Questions - query:
• give a account with balance over 1000
• apply all the events and find ?
• e.g. Sn = reduce(E, S0, apply)
• Solution:
• How about saving in a relational database
• to feed your events ?
18

19. Welcome to CQRS
19

20. Welcome to CQRS
• Command
• Query
• Responsibility
• Segregation
• Separate Query and Command objects to retrieve and modify data, respectively
20

21. CQRS
• Separate write and read models
• Trandationally, databases are:
• fast to write, slow to read
• slow to write, fast to read
• CQRS allows us to be FAST TO WRITE AND FAST TO READ.
21

22. CQRS
•
22

23. CQRS
• Commands: Represent requests to action something made by the end user, that will
be processed by the application.
• Events: Changes made to the data , and are raised as a result of actioning Commands.
These classes are serialised into the Event Store.
• Aggregate: Comprised of its state, public command functions, and state mutators.
• Event Store: The place where the Events are stored
23

24. Commanded
• Elixir lib
• Helps you build the event source command side of application
• Use Commanded to build Elixir applications following the CQRS/ES pattern
24

25. What are Commands?
• Commands are requests sent by the end user to the application, instructing the app to
do something.
• When our application receives a command
• process it to figure out what the end-user wanted the app to do
• then raise the appropriate Events to accomplish that task
25

26. What are Commands?
• Defining the Commands
• Create a module per command and define the fields using defstruct
defmodule Coins.Commands do
defmodule MineCoin do
defstruct [
:account_id,
:nonce
]
end
end
defmodule Coins do
def mine_coin(account_id, nonce) do
%Commands.MineCoin{
account_id: account_id,
nonce: nonce
}
end
end
26

27. What are Commands?
• A request
• e.g. MineCoin(account_id:1234, nonce:“nonce”)
• May fail
27

28. What are Events?
• Changes made to the state of the system that result from the end-user issuing
Commands.
• Serialised and stored in the Event Store, so that they can be recalled and re-executed
at a later time
• Named in the past tense: account registered; funds transferred…
28

29. What are Events?
• Defining the Events
• Defining the Commands
defmodule Coins.Events do
defmodule CoinMined do
defstruct [
:account_id,
:nonce
]
end
end
defmodule Coins.Commands do
defmodule MineCoin do
defstruct [
:account_id,
:nonce
]
end
29

30. What are Events?
• A fact
• In the past
• e.g. CoinMined(account_id:1234, nonce:“nonce”)
30

31. Aggregates
• Command Handlers
• raise corresponding Events
• state changes with Events
31

32. Aggregates
• For business rule violations and errors
• State of an aggregate can only be mutated by applying a domain event to its state
@spec execute(state, command)
::{ok, [event]}
| {:error, term()}
@spec apply(state, event) ::state
32

33. Aggregates
defmodule Coins.Account do
def execute(%{last_nonce: ln}, %MineCoin{nonce: n})
when n < ln,
do: {:error, :used_nonce}
def execute(_, %MineCoin{} = cmd) do
# if Proof.proof(cmd.nonce)
%CoinMined{
#...
}
else
{:error, :invalid_nonce}
end
end
def apply(state, %CoinMined{} = evt) do
%Account{state | last_nonce: evt.nonce}
end
end
33

34. Aggregates
• Command functions
• receives the aggregate’s state and the command to execute
• return the resultant domain events
• State mutators
• mutated by applying a domain event to its state
34

35. Now we have…
• Command
• Event
• Aggregate
• how to dispatch command to event?
35

36. Then we need …
• Router a command directly to an aggregate
defmodule Coins.Router do
use Commanded.Commands.Router
alias Coins.Account
alias Coins.Commands, as: C
dispatch(
[
C.MineCoin
],
to: Account,
identity: :account_id
)
end
alias Coins.{Commands, Router}
def mine_coin(account_id, nonce) do
%Commands.MineCoin{
account_id: account_id,
nonce: nonce
}
|> Router.dispatch()
end
36

37. Then we need … 37

38. Then we need …
• EventStore
• Uses PostgreSQL as the underlying storage engine
• Usage:
• Read all events from a single stream
38

39. Then we have …
iex(1)> Coins.mine_coin("monkey", 2)
:ok
iex(2)> Coins.mine_coin("monkey", 4)
:ok
iex(3)> Coins.mine_coin("monkey", 5)
{:error, :invalid_nonce}
iex(4)> EventStore.stream_all_forward() |> Enum.to_list()
[
# ...,
%EventStore.RecordedEvent{
created_at: ~N[2018-10-30 22:51:51.262611],
data: %Coins.Events.CoinMined{account_id: "monkey", nonce: 2},
event_id: "3d1d4ca2-b453-4f4b-9e0c-1fd8668e1ba6",
event_number: 11,
stream_uuid: "monkey",
stream_version: 1
},
%EventStore.RecordedEvent{
data: %Coins.Events.CoinMined{account_id: "monkey", nonce: 4},
event_number: 12,
stream_uuid: "monkey",
stream_version: 2
},
39

40. Then we have …
iex(5)> Coins.mine_coin("typewriter", 7)
{:error, :invalid_nonce}
iex(6)> Coins.mine_coin("typewriter", 6)
:ok
iex(7)> Coins.mine_coin("typewriter", 4)
{:error, :used_nonce}
iex(8)> EventStore.stream_all_forward() |> Enum.to_list()
[
# ....,
%EventStore.RecordedEvent{
data: %Coins.Events.CoinMined{account_id: "typewriter", nonce: 6},
event_id: "d0cec127-d69b-488c-b316-20b6ec66230d",
event_number: 13,
stream_uuid: "typewriter",
stream_version: 1
}
]
40

41. Then…Read model Projections
• Commanded Ecto projections
41

42. Then…
• Kafka
42

43. Questions?
43

44. Arcblock Learning Series - hack.arcblock.io/learning/
44

45. 45