Last Monday, at the August meetup of Bonn Agile, I did a talk about architectures based on the CQRS pattern. I presented various opportunities enabled by this pattern, specifically asymmetrical scaling, separating the models for reading and writing, eventual consistency, and event sourcing. I also put up some very crude demo code in Scala to show how one might implement a command handler and a write model handler, and how easy it is to build the current state of an aggregate from the events stored for it.
Although the pattern and the architectural decisions it enables haven't made their way into the mainstream yet, a couple of people had at least heard of them. Since I was speaking to an audience of agilists, I tried to bring two questions into the focus of the discussion:
- How can such an architecture help us be more agile?
- When does it rather hinder us from being agile?
I might put my thoughts on these topics into a blog post if there is sufficient interest in that.
What I really found interesting about the evolving discussion at the end of my talk was the fact that some people have built applications in which events are actually an almost natural part of the domain model. Apparently, they implemented some of the ideas behind event sourcing, but without really knowing about it, so events did not play the first class role that they have in an event-sourced architecture. This suggests that currently, CQRS-based architectures, and especially event sourcing, are indeed under-used.
Link: Slides