Because of time contraints, the lack of experience on my team, and the small size, I don't think it's feasible to try to implement event sourcing right now on a new system we are building. However, I want to do something where I can at least start saving the events for future use and I'm looking for some way to do this that's not overly complicated. Does anyone have any suggestions? I'm thinking of something like cqrs and dropping the events into a nosql store to later be moved into a reporting database.
I don’t know what language/framework/technology you’re intending to use in your new project, so YMMV, but my experience taught me that the best moment to do event-sourcing is right from the start. It may seem overwhelming at first, but the fact is migrating an existing application to event-sourcing after the fact is somehow tedious and painful.
If you’re in the scala/java/akka world, you’re blessed : akka-persistence will do (almost all) the job for you, and I think someone familiar with akka can skim through the docs and become productive with akka-persistence in a few hours (there’s also a port of Akka in .NET, but I don’t know how complete it is).
The good thing there is that you can start with a simple storage backend for your journal (eg local disk) and later switch to a full fledged database (eg eventstore) without changing your business code (but you’ll of course have to move your data from local disk to database).
So my (humble) advice is : if you’re willing to do (CQRS+) event-sourcing, just go ahead and do it from the start, it will be extremely rewarding in the long run, and you may even find it to speed up your development.
I know of a perfect nosql database for storing events: geteventstore.com. Even if you won't be using it as your system of record from the start (I agree you should from the very start if you ever plan to make it so) you can still store the events there after the fact.
I've used akka.net and it is excellent with an outstanding community and consistent contributions. Though I haven't yet used akka.net persistence, I understand it to be at least very far along, if not production ready.
There is a lon (100 email) thread on the akka list about querying APIs and akka.persistence. The current API is quite far from what is needed. The current suggestion is to not use the API for querying.
That’s my conclusion as well, but I’m very early in on my first Akka.net project. Writeside seems fine, but readside need a lot of plumbing. (catchup on eventbus, buffering, transaction handling etc). I’ll se if it’s possible to break out these parts as a contrib-project or something later on…
This would be awesome. I’m currently using one of the ones listed below. I’ll have to take at look at the Akka(scala) one to see what capabilities it has.
