Trying out CQRS and Event Sourcing for a day
Last Friday, Jonathan Worthington and I (Carl Mäsak) decided to get our feet wet with CQRS and event sourcing. The toy project we settled on: a simple but realistic web site for two-player board games.
In this post, I summarize how things went.
Architect meets domain expert
Since there were only the two of us, I took the role of the domain expert, and Jonathan took the role of the architect. He expertly teased a model out of me. We arrived at two aggregate roots:
Game. Easy enough.
Design: commands and events
RegisterPlayerCommand ActivatePlayerCommand InvitePlayerCommand AcceptInvitationCommand RejectInvitationCommand (no StartGameCommand) PlaceStoneCommand SwapPlayerColorsCommand ResignGameCommand TimeOutGameCommand PlayerRegisteredEvent PlayerActivatedEvent PlayerInvitedEvent GameStartedEvent InvitationRejectedEvent StonePlacedEvent GameWonEvent PlayerColorsSwappedEvent GameResignedEvent GameTimedOutEvent
For each command and event, we took a moment to model through what data we needed to send along. It gave us an appreciation for one of the ways in which commands and events differ: on the inside.
There was a moment of joyful insight as we realized that we had gotten this far into the design of the system and not once talked about state. Quite a
Being the one with the “domain expert” knowledge, I kept unwillingly slipping back into the role of the client. Otherwise we’d have gotten some things wrong, which wouldn’t have shown up until the next “meeting with the client”. Jonathan remarked: “There’s got to be a lesson in here somewhere.”
(Afterwards, we’ve changed two things in the above model: we eventually realized that we would need an
InvitationAcceptedEvent after all. The reason we originally figured we’d be able to do without it is that we noticed that it would fire off a
GameStartedEvent, and that would be enough. But no, it needs to fire off both, otherwise the
Invitation would still be open. The other thing we realized was that a better name for
PlayerInvitedEvent would be
InvitationMadeEvent. That way, all the commands and events contain in their names the aggregate that they are acting on — which makes a lot of sense.)
Commands, events, test framework
We wrote our first test, and the necessary classes to go with it.
Our goal now was to get enough of the system running for our first test to fail. That took a few hours, partly due to the fact that we were figuring out how to fit everything together.
The wiring is like this: The test contains a ‘given’ list of events, a ‘when’ command, and a ‘then’ list of events or an exception. The test fixture creates an aggregate root to do the testing on, and loads it up with the events from the ‘given’ part. Aggregate roots have a special flag on the
apply_event method for applying events without having them register as changes to be committed. That’s all the concession to testing that’s needed. Quite neat.
The test fixture then sends the command to a bus-like thing. This triggers the right command handler, which does the required validation and then calls a method on the aggregate. That’s the command part of things.
Now, the method on the aggregate is just a thin wrapper for applying an event. The event is mapped through a lookup table (our workaround for the lack of method overloading in Perl 5) to an apply-event method. Note that on the way, we visited the same
apply_event method as when we prepared the aggregate with the ‘given’ events. This time the generated events are saved, though… and that’s exactly what we’re then using to check against the ‘then’ events. (Or, if we got an exception, the test fixture captures that and compares it with whatever was expected.)
It’s quite a simple system, though it took us a few hours to understand and get running. Still not too bad for our first attempt.
Getting the first test to pass
Trying to get the test we’d written at the beginning of the day to pass, we realized that we were still missing one component: a repository to store the aggregate in while we were testing it. We settled on writing a test repository, with a total capacity of one (1) aggregate.
After that, things fell into place quickly. We got our event wired up, and the test passing. Thus, we entered into the next phase…
Ping-pong pair programming
By the looks of the commit log, that’s where I became unconscious and Jonathan kept on hacking.
:-) But what really happened is that we paired up over Jonathan’s keyboard and started hacking in earnest.
Ordinary pair programming has a “driver” and a “navigator”. In ping-pong pair programming, the idea
is for the two people to alternate by taking turns writing a test for the other to implement. This was the first time we tried that, and it went very smoothly. Definitely something to try again. In regular pair programming, the navigator can sometimes doze off. But doing things this way, both of us were engaging with the process of writing code and tests, even when we weren’t in the role of driver.
We got through eight such cycles of ping and pong. At this point, things were really effortless: all the groundwork was already made, and now that we were finally implementing state in our aggregates, there were no longer any obstacles left. A very weird feeling; the aggregate was its own little world, merely responding to commands and events as they came flying by. Coding was effortless, not least because we managed to time it with the Ballmer Peak.
:-) Mmm, beer.
We surprised each other a bit by turning what appeared to be quite tricky tests into excessively simple bits of implementation. Things generally required less wiring up than we expected. (Again, because object state wasn’t the driving component, leaving us free to structure the innards of an aggregate any which way we wanted.)
One thing we also discovered is that we generally had to write fewer tests than “usual”. Each new test covered a bit more ground than we expected, and we often didn’t bother to write a test because we already knew it was going to pass. We’re not sure whether that’s (a) a good thing, and we shouldn’t worry, (b) a bad thing that’s going to cost us in the future, or just (c) a sign that we knew too much about the implementation. Guess more practice with this way of testing will tell.
All in all, a happy first day with CQRS and event sourcing in actual practice.
Carl Mäsak has a passion for software and software process. He works as an architect and programming mentor at Edument. He likes to work on healing systems in need of an architecture, or to help introduce order into a chaotic domain. On his spare time, he rides a bike, cooks food, and writes music. Not necessarily all at the same time.
Upcoming CQRS events
Edument will arrange a Software Architecture – Community Day in Malmo, Gothenburg and Stockholm.
Entry filed under: Uncategorized.