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
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, there's a centralized list of reported issues. These do not imply an actual roadmap, just what has been reported, ranging from bugs to longer-term design issues.
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:
For more details, please refer to CONTRIBUTING