Eventsourcing for Java

Keep the past, because predicting future is hard

Instead of mutating data in a database, Eventsourcing stores all changes (events) and what caused them (commands). To make this data useful, Eventsourcing builds indices over it.

This helps developing applications faster because there is no need to worry about designing the right domain models upfront (or as close to right as possible). By keeping all the commands and events, we can enrich or change our domain models over time with very little friction. Furthermore, this approach removes a need to have a one and only domain model for every entity. We experience the world and reality in different ways, depending on circumstances and points of view, and our programs should be able to reflect that.

To learn more about what kind of problems ES4J addresses, please read Why Use Eventsourcing Database

Key benefits

Domain model flexibility
Late domain model binding
Persistence of causal information
Serializable conflict resolution
Audit trail logging
Mapping application functionality

Key features

Strongly typed schemas
Event migrations
Domain protocols
Batteries included (shared event languages)
Basic support for Kotlin
Causality-preserving Hybrid Logical Clocks
In-memory, server (PostgreSQL) and on-disk (H2/MVStore) storage
Locking synchronization primitive
JMX-based introspection and management

Presentation

You can find our current slide deck at https://eventsourcing.com/presentation

Documentation

Installation instructions and documentation can be found at es4j-doc.eventsourcing.com

We strive to specify the building blocks behind Eventsourcing and its ecosystem as succinct specifications, you can find the current list of them at rfc.eventsourcing.com

Roadmap

As this project is striving to be a decentralized, community-driven project governed by the C4 process, there is no central roadmap per se. However, individual contributors are free to publish their own roadmaps to help indicating their intentions. Current roadmaps available:

Yurii Rashkovskii

Also, there's a centralized list of reported issues. These do not imply an actual roadmap, just what has been reported.

Snapshot versions

Every successful build is published into a separate Maven repository on Bintray (using a git describe version), you can find the last snapshot version mentioned in a badge at the top of this file.

Gradle configuration:

repositories {
    maven {
        url  "http://dl.bintray.com/eventsourcing/maven-snapshots"
    }
}

Maven configuration:

<repository>
	<id>bintray-eventsourcing-maven-snapshots</id>
	<name>bintray</name>
	<url>http://dl.bintray.com/eventsourcing/maven-snapshots</url>
</repository>

Contributing

Contributions of all kinds (code, documentation, testing, artwork, etc.) are highly encouraged. Please open a GitHub issue if you want to suggest an idea or ask a question.

We use Unprotocols C4 process. In a nutshell, this means:

We merge pull requests rapidly (try!)
We are open to diverse ideas
We prefer code now over consensus later

For more details, please refer to CONTRIBUTING

Related projects

es4j-graphql A Relay.js/GraphQL adaptor for ES4J-based applications.

mhmodsn / es4j