Now before I ask this question, I want to preface by stating that this
is purely an intellectual debate, and not intended to slight in any
way!
That said, should event sourcing be included in axon itself or should
it be separated entirely?
First, you can do CQRS without event sourcing. Second, axon really
only ships with one implementation (JPA), which incurs the overhead of
the ORM in translating events (I've got my own JDBC impl that I'll
give back to the community soon). If you take a look at Jonathan
Oliver's Event Store, he has many persistence engines supported, and
eventually I'd like to see that become available in Java as well.
I completely agree that Event Sourcing is nothing more than an implementation detail of the storage. Except that Aggregates need to be suitable to source them using events, of course.
In Axon, event sourcing is included in the core jar, but is contained in a separate package. I did this to be able to separate things into different jars. In the 2.0 version, that might just be something I’ll do. Mostly to make clear that ES is a choice. And one not to be taken too lightly. But Event Soucing itself, in my belief, should be part of Axon as a whole.
Work is underway implementing Event Stores using Redis and MongoDB, as well as a high-speed disk based version. But I’m lacking time to implement all of them. Any support is highly welcome!
Oh I definitely hear you there I'm eventually going to move to
Cassandra for my app it appears, so I could contribute there. I've
got at least another month before go live, so my hands are tied until
then. High speed disk might get tricky when you consider local vs
remote file systems (e.g. CIFS/NFS). I had considered something along
the lines of that via NFS, but again, not enough time to do proper
performance testing yet
A Cassandra based event store is definitely very high on my wish list. Cassandra seems to suit many of the Axon-type applications very well. A contribution here would be very, vert much appreciated.
