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

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

• 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

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

To start using ES4J, please follow the installation instructions.

Documentation can be found at es4j.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

As this project is striving to be a decentralized, contributors-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.

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

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