Episode 5: CQRS EventStore – Best Framework/Library Ever!
In this episode we discuss the CQRS EventStore project. We talk about the history behind the project, why and how it can be used as well as some of the benefits of the project when using the event sourcing pattern.
MP3 Download: Distributed Podcast, Episode 5
Episode references
Great show! A few things which I felt were missing are:
- how commits tie back into streams and those in turn to aggregates (or sagas),
- how a commit is oriented around the idea of the command that caused it (and thus the “one command affects one stream/aggregate” mantra).
Regards,
Yves.
A series of commits (which itself is composed of one or more events) is a stream. The EventStore library doesn’t concern itself with hydrating an aggregate, but I’ve been kicking that idea around recently.
Also, there doesn’t need to be a direct correlation to the command that caused the commit. If you want the EventStore to prevent duplicate commits, you simply give each commit a unique identifier which comes from the message (command) that caused the commit. If deduplication isn’t important, then you don’t need to worry about it.
Great library, agreed. Best ever? We’ll see.
I’m concerned about the masterless system idea. I’ve done this successfully, but only after adding the concept of partial order to events.
Events tend to be independent of other events outside of their immediate aggregate, but within an aggregate the order is very important. Unless you have only one command handler for that aggregate, the events could get out of order as you merge them. Timestamp is not sufficient to save you, since events could occur within the error between two server’s clocks.
Instead, I make the later event reference its predecessor. With that information, I can always assemble events in order when necessary. Unrelated events do not reference one another, and can be safely assembled in any order.
It’s probably not the best library ever, but it’s sure a lot of fun to say. I’ve seen your stuff before and it differs from Greg Young’s stuff in a number of interesting ways.
The way we handle masterless systems is by having partial ordering to events and then performing a merge between the various streams of events for a given aggregate. In general, we would only get into this situation during a network partition.
Hi there,
Really enjoying the podcast so far. I’ve only made it up to number 3 thus far.
I was thinking that you guys could talk about the existing CQRS examples and frameworks that are out there and what the good/bad things about them are E.g.
http://ncqrs.org
https://github.com/MarkNijhof/Fohjin
http://codebetter.com/gregyoung/2010/08/31/super-simple-cqrs-example/
CQRS Kitchen
etc.
Also perhaps ways to migrate an old system over to cqrs would also help a lot of people out I’m sure
That’s on the show roadmap–migrating from brownfield to CQRS. I don’t have a time frame yet for when we’ll record on this topic.
I just finished listening to the first 5 podcasts back-to-back, great series. I am looking forward to the brownfield episode. I have what I hope is a quick question, for the event store in your experience how would you handle a multi-tenant setup where each tenant is in there own db instance? Would have an event store in each tenant’s instance and have the system know how to connect to each one or would you have one global event store and add a tenant id to the event store table?
Thank you and please keep the episodes coming.
There are a number of ways to accomplish this. The most clear-cut is having an instance of the EventStore per tenant. I’m actually doing multi-tenant in production but it’s very different from what others do. I’m actually using the headers property of the commit. When I save I put the tenant identifier into the commit. Then when I read I compare the currently executing tenant to the one that’s stored. If they don’t match I throw a security exception.
First of all: I am really enjoying your podcasts.
However, I have a few questions:
– What is it with you guys and the springframework.net?
– Why is the retry-logic and the fact that you get it basically for free with messaging so important for you? Albert Einstein once defined Insanity: doing the same thing over and over again and expecting different results.
– If you have to take dependencies on IoC container for the EventStore project, I suggest to use the common service locator so the EventStore is interoperable with the biggest / most common containers http://commonservicelocator.codeplex.com/
Thanks for your time creating the podcast – I am looking forward to the next episode!
Spring.NET has a number of quirks. It’s been a while since I’ve looked at the project, but at the time, it was very XML configuration heavy, didn’t have a lot of basic features such as child containers, etc. We’ve all moved on to more capable containers and haven’t looked back. It’s very much like a SourceSafe to svn paradigm shift. Or better yet, svn to git or hg.
The reason that retry is important is relative to transient failures and system outages. The network isn’t reliable, so retry is critical. After X retries, if the message cannot be delivered, it’s marked as “poison” and forwarded to an error/poison queue for inspection.
The EventStore doesn’t actually have a dependency on a real container–it’s container agnostic. There is a “wireup” project, but it doesn’t really need a full-blown container. Even then, it’s not required that you use the fluent wireup. You’re more than welcome to bring your own container such as Spring.NET or otherwise and it will work. At the same time, the “nano container” that is a part of wireup is like 25 lines of code–as compared to the 100+ KB for the CommonServiceLocator.
I really blog as well and I am writing a thing related to this specific post, “Episode 5: CQRS EventStore – Best Framework/Library Ever!
”. Do you mind in the event I reallyuse a few of your personal ideas?
Thank you ,Kathleen from Prime Solar Window Shades