Is there a Java port or equivalent of the NEventStore library?

Question

I've read up on Jonathan Oliver's .NET EventStore library, and I must say the concept appeals to me a lot: having just a simple no-dependencies library which is non-intrusive and just focuses on event sourcing, leaving a lot of freedom when choosing technologies for databases, messaging, etc.

My question: Is something similar also available in the Java world? I know there are all kind of CQRS-related frameworks, like Axon and Jdon, but those do a lot more than just event sourcing... Anyone working on a straightforward port, perhaps?

Answer 1

I'm not aware of any that exist. At the same time, it wouldn't be terribly difficult to write one. The hardest part for me in writing the EventStore was arriving at the correct model. I had two private/internal releases within my company, and then two public releases before I was really satisfied with how things turned out. There are a few Ruby ports and other languages as well, and usually they take a few hours to write because the authors copy the model. If you take the same approach, I don't see why you couldn't write your own within a few hours.

Answer 2

I realize the question is old, but for those in a similar position now: you could try Greg Young's EventStore (http://geteventstore.com)

It needs .NET or mono to run but there is a JVM-based client library: https://github.com/EventStore/eventstorejvmclient

Answer 3

You could have a look at Occurrent which is designed to be used as a library. This means that you can use only the event store, and nothing else, and add more components when you find fit.

It's also designed to integrate well with popular frameworks such as Spring Boot if you want to use a framework on top (without necessarily having to use framework-specific code in your domain model).

Answer 4

In theory, it could support messaging, but appears to only support databases currently.

Using JDBC is not that much of an imposition and can wrapped up to suit your needs fairly easily. If you want simplicity, I would use JDBC.

If you want to support JMS (messaging) I would use only that (with an adapting service to any database you want to use) This gives you simple standard event driven interface for all types of messaging (and any database you connect to)