Strongly inspired by:

• Versioning in an Event Sourced System by Greg Young
• The dark side of event sourcing: Managing data conversion by Michiel Overeem, Marten Spoor & Slinger Jansen

---

Jes is a framework to build robust, event-driven microservices in a CQRS & ES paradigm. Jes provides several abstractions, that help to organize the workflow of your application, and hide all the mess.

---

Getting started

Prerequisites

1. java 8
2. build tool like maven or gradle

You can start using Jes by simply adding the following dependency into your pom file:

<dependency>
    <groupId>store.jesframework</groupId>
    <artifactId>jes-core</artifactId>
    <version>${jes.version}</version>
</dependency>

Spring Boot Jes Demo

Building from source

git clone https://github.com/egetman/jes.git
cd jes
mvn install -DskipTests

Overview

There are some typical patterns for mainstream apps for which Jes is perfect:

1. webapps with lots of user interaction

   

   • a user interacts with the system via queries and commands
   • queries are read-only
   • commands can be accepted or rejected when received by command handlers
   • command handler uses optimistic locking when writing events
   • each projection tails the event store and processed new events if needed

2. event-driven apps with lots of automatic processing

   

   • client emits commands to process
   • commands can be accepted or rejected when received by command handlers
   • command handler can use optimistic locking when writing events
   • each saga tails the event store and processed new events if needed: it can trigger compensation action via command, trigger new business logic via command or call an external service
   • sagas are distributed components with proper sync
   • sagas can be stateless or stateful. When stateful - state shared between all instances and all state changes use optimistic locking
   • stateful saga is an event-sourced saga

3. hybrid apps, which combines 1 & 2 types in some proportion

Features

Feature	Subsection	Description
event stream corrections		what to do if something goes wrong?
	event stream split	it can be useful when you need, for example, split event stream for the anonymous one and another, that contains clients personal data
	event stream merge	as a split, it can be useful when you want to combine different streams
	event stream deletion	optional operation. You can use it when, for example, you need to delete all user-related information, that bounded to a specific stream
	copy-and-replace	you can read about it here
versioning		how your system will evolve?
	multiple event versions	you can live with several concurrent event versions
	upcasting	if you want to handle 'always last' version of an event - upcast it (from the 'raw' representation - no intermediate representations, you better know how to transform your data)
	copy-and-transform event store	you can read about it here
core
	tails directly event store: no more unreliable event publishing	you can watch this talk by Greg Young if you want to ask 'why?'
	strong/weak schema formats (partial)	there are several formats you can use for the event store
	pull-based projectors	there is no 'control communication channel' - each projection is independent, you can change it how you like
	snapshotting	have a long event stream? It's not a problem
flow
	optimistic locking	perfect for user-related communication

Components overview

You can find components overview on the related wiki page.

Example configuration

You can find spring-related example configuration on the wiki page.

Contributing

Please refer to the contributing guide.