Command / Query Responsibility Segregation, Event Sourcing and a little Domain Driven Design with examples in PHP

1. CQRS / ES
by Vic Metcalfe / @v_metcalfe
Command / Query
Responsibility
Segregation, Event
Sourcing and a little
Domain Driven Design

2. Welcome
• Not an expert
• Over 60 slides, many containing code
• Ask questions at any time, expect short
answers / discussion
• Q & A after 30 minutes, or talk to me after

3. CRUD
CREATE / REPORT /
UPDATE / DELETE
UPDATE AND
DELETE DESTROY
DATA
HOW MUCH WAS
THAT DATA WORTH?

4. Treat the storage of
data as a separate
problem from the
retrieval of data

5. THE RIGHT WAY
THE RIGHT WAY

6. Everything you
need to know
about Event
Sourcing, you
can learn from
git
accounting
or

7. Why so
difficult?
CQRS
DDDES

8. Domain Driven
Design
• Helps business stakeholders think about their
requirements
• Helps developers adapt their software models
to the problem domain

9. DDD Strategies
• BDD (Behaviour Driven Development)
• CI (Continuous Integration)
• DTO (Data Transfer Object)
• Bounded Contexts
• Domain Events / Event Storming
• CQRS / ES
• …more!

10. Command /
Query
Responsibility
Segregation
CQRS naturally emerged from DDD
Read
Models
Write
Models
Emerge naturally from
events
Emerge naturally from
how we use our data

11. Event Sourcing
ES naturally emerged from CQRS
The Event Store is TRUTH

12. Working
Definitions
• Command
• Event
• Aggregate
• Aggregate Root

13. Command Communicates an INTENT to change the
application’s state

14. Event Records the FACT that a thing happened that
changed the application’s state

15. Aggregate A data model that is built up by the events that
contributed to it’s state

16. Aggregate Root
An aggregate that has a unique identifier.
It may contain:
• Other aggregates
• References to other aggregate roots

17. Command Events

18. function command($parameters)
{
if (!$this-validateParams($parameters))
{
throw new InvariantException();
}
// Determine resulting events
return [ $event, $anotherEvent ];
}

19. Discussion
Points
• Where should we place our commands?
• Can commands say no?
• Distributed systems and CQRS

20. Events Aggregate

21. /** @Apply(User::SOME_EVENT) */
protected function didSomething($id, $payload)
{
$this->field = $payload['key'];
}

22. Discussion
Points
• Annotations?
• Where should we place apply methods?
• Why pass both ID and payload?

23. Event Projections

24. /**
* @Projector(Aggregate::SOME_EVENT)
*/
function onSomeEvent($id, Event $event)
{
// Update read model(s)
}

25. Discussion
Points
• Where should we place projectors?
• Should projections live in the same database
as our events?
• Batch and asynchronous projections

26. Event
Process
Manager
Commands

27. /**
* @ProcessManager (ProcessManager::SOME_EVENT)
*/
function onSomeEvent($id, Event $event)
{
// Invoke some command(s)
}

28. Discussion
Points
• Where should we place process managers?
• They look like projectors – why do we need
both?
• Why not just have process managers create
events directly?

29. Working
Definitions
• Event Stream
• Invariant
• Ubiquitous Language
• Bounded Context
• Snapshots

30. Event Stream An ordered list of events for a specific aggregate
root

31. Invariant
• Business Rule
• Enforced by Commands

32. Ubiquitous
Language
• Definitions that have specialized meaning
within our problem domain
• Updated as needed when terminology evolves
in a project team

33. Bounded
Context
• A specific problem domain
• A project may contain just one or many
• An aggregate is defined within a single
bounded context

34. Snapshots
• Specialized projections that capture an
aggregate root at a specific version
• Load from snapshot and update from events

35. Concurrency
Aggregate
Root
Command
Events
Record
Start over
on version
mismatch
Load an aggregate root
before initiating a
command for it

36. Concurrency
Aggregate
Root
Command
Events
Record
Start over
on version
mismatch
Command enforces
invariants based on a
specific version of the
aggregate root

37. Concurrency
Aggregate
Root
Command
Events
Record
Start over
on version
mismatch
Command generated
events which will be
recorded into an event
stream.

38. Concurrency
Aggregate
Root
Command
Events
Record
Start over
on version
mismatch
Events (and maybe
some projections) are
recorded in a single
transaction so they are
all recorded, or none
are recorded

39. Concurrency
Aggregate
Root
Command
Events
Record
Start over
on version
mismatch
If the current version
isn’t the same one the
command acted on,
throw out the events
and retry a few times.

40. Reliability
• The impact of bugs is reduced by the
immutability of event streams
• Lower complexity* makes bugs less likely and
code easier to test
* Assuming our application is non-trivial and that CQRS/ES results in
lower complexity!

41. Flexibility
• Separation of concerns
• Tends to be implemented in short simple
functions, or small simple classes
• “If we’d recorded that in the database it
wouldn’t be a problem”
• “That report will be slow because of too many
joins”

42. Scaling
• Different aggregate root types can use
different event stores / databases
• Projections can live on different databases
• Projections can use the most appropriate
database technology (relational, no-SQL,
graph, etc.…)

43. Security
• Event store can be read and append only
• Projections can be audited
• Web application can have read-only rights to
projections

44. Concrete
Example
• User Registration
• Email Confirmation
• One projection; one process manager

45. Feature: Register a new client
So that I can borrow books, as a guest I need to create an account on the system.
Background:
Given that I am a guest on the registration page
And I have filled in "pat@example.com" for my email address
And I have filled in "letmein" for my password
Scenario: Register a new Client
When I click the register button
Then I receive an email to "pat@example.com" asking me to confirm my email address
And my password is "letmein"
Scenario: Confirm Email Address
Given I click the register button
And I receive a confirmation email
When I follow the link in the confirmation email
Then my account is confirmed

46. /**
* @When /^I click the register button$/
*/
public function iClickTheRegisterButton()
{
try {
list($id, $token) = explode(';', $this->emailConfirmationToken);
$this->streamManager->recordCommand(
1,
[$this->userCommands, 'register'],
1, $this->registrationForm['email'], $this->registrationForm['password'], $token
);
} catch (Exception $e) {
$this->lastException = $e;
}
}
features/bootstrap/UserContext.php

47. Record
Command
Aggregate
Root
Command
Events
Record
Start over
on version
mismatch
The record command
call on the last page
looks like this inside

48. public function register($user, $id, $email, $hashedPassword, $token)
{
if (!is_null($user)) {
throw new InvariantException("Only new users can register. " .
"User $id has already been registered.");
}
$stmt = $this->db->prepare("select id from user where confirmed_email=:email");
$stmt->execute(['email'=>$email]);
$row = $stmt->fetch(PDO::FETCH_ASSOC);
if ($row !== false) {
throw new EmailAlreadyRegisteredException();
}
Projection
src/Model/User/UserCommands.php

49. $stmt = $this->db->prepare("select id from user where requested_email=:email");
$stmt->execute(['email'=>$email]);
$row = $stmt->fetch(PDO::FETCH_ASSOC);
if ($row !== false) {
throw new EmailAlreadyPendingException();
}
return Event::NamedPayloadPairsToArray(
User::REGISTERED, [],
User::PROVIDED_EMAIL_ADDRESS, ['email' => $email, 'token'=>$token],
User::CHANGED_PASSWORD, ['password'=>$hashedPassword]
);
Projection
src/Model/User/UserCommands.php
There’s a much better way to enforce unique emails by using a
separate aggregate root with email keys and Associate /
Disassociate commands, but that wouldn’t fit into a ½ hour talk!

50. /** @Apply(User::REGISTERED) */
protected function registered($id)
{
$this->id = $id;
}
/** @Apply(User::PROVIDED_EMAIL_ADDRESS) */
protected function providedEmailAddress($id, $payload)
{
$this->email = $payload['email'];
$this->emailConfirmationToken = $payload['token'];
}
/** @Apply(User::CHANGED_PASSWORD) */
protected function changedPassword($id, $payload)
{
$this->password = password_hash($payload['password'], PASSWORD_DEFAULT);
} src/Model/User/User.php

51. /** @Projector(User::REGISTERED) */
public function OnRegistered($id)
{
$stmt = $this->connection->prepare("insert into user (id) values (:id)");
$stmt->execute(['id'=>$id]);
}
src/Model/User/Projector/UserListProjector.php

52. /** @Projector(User::PROVIDED_EMAIL_ADDRESS) */
public function OnProvidedEmailAddress($id, Event $event)
{
$payload = $event->getPayload();
$stmt = $this->connection->prepare(
"update user set requested_email=:email where id=:id");
$stmt->execute(['id'=>$id, 'email'=>$payload['email']]);
}
src/Model/User/Projector/UserListProjector.php

53. /** @Projector(User::CHANGED_PASSWORD) */
public function OnChangedPassword($id, Event $event)
{
$payload = $event->getPayload();
$stmt = $this->connection->prepare(
"update user set password=:password where id=:id");
$stmt->execute(['id'=>$id, 'password'=>$payload['password']]);
}
src/Model/User/Projector/UserListProjector.php

54. /** @ProcessManager(User::PROVIDED_EMAIL_ADDRESS) */
public function providedEmailAddress($id, Event $event)
{
$payload = $event->getPayload();
$this->stream->recordCommand(
$id,
[$this->userCommands, 'sendEmailConfirmationMessage'],
$payload['email'], $id
);
}
src/Model/User/ProcessManager/SendEmailConfirmation.php

55. src/Model/User/UserCommands.php
public function sendEmailConfirmationMessage(User $user, $email, $id)
{
$confirmationCode = $user->getEmailConfirmationToken();
$message = (new Swift_Message("Please confirm your email address"))
->addTo($email)
->addFrom($this->confirmationFrom)
->setBody("Please confirm your email with $id;$confirmationCode.")
;
$this->mailer->send($message);
return Event::NamedPayloadPairsToArray(User::SENT_CONFIRMATION);
}

56. features/bootstrap/UserContext.php
/**
* @When /^I follow the link in the confirmation email$/
*/
public function iFollowTheLink()
{
list($id, $token) = explode(';', $this->emailConfirmationToken);
$this->streamManager->recordCommand($id,
[$this->userCommands, 'confirmEmail'],
$token
);
}

57. src/Model/User/UserCommands.php
public function confirmEmail(User $user, $token)
{
if (!$user->matchEmailConfirmationToken($token)) {
return []; //Like nothing happened, for now we will ignore failed attempts
}
return Event::NamedPayloadPairsToArray(User::CONFIRMED_EMAIL);
}

58. src/Model/User/User.php
/** @Apply(User::CONFIRMED_EMAIL) */
protected function confirmedEmail()
{
$this->confirmedEmail = true;
}

59. src/Model/User/Projector/UserListProjector.php
/** @Projector(User::CONFIRMED_EMAIL) */
public function OnConfirmedEmail($id)
{
$sql = "update user set confirmed_email = requested_email where id=:id";
$stmt = $this->connection->prepare($sql);
$stmt->execute(['id'=>$id]);
}

60. Future State
• Temporal “what if” queries
• Offline Events – mobile
• Ephemeral Event Stores for temporary state
• Greater adoption of non-distributed CQRS

61. Resources
• Domain Driven Design Quickly
• https://www.infoq.com/minibooks/domain-driven-design-quickly
• Head First Domain Driven Design
• http://headfirstdomaindrivendesign.com/
• Prooph – CQRS for PHP
• http://getprooph.org/
• CQRS Journey by Microsoft
• https://docs.microsoft.com/en-us/previous-versions/msp-n-p/jj554200(v=pandp.10)

62. Thank you!
• Wrap up
• Q & A