Introduction

The documentation is always for the latest version of Occurrent, currently 0.34.0.

If you like Occurrent, please consider starring us on GitHub:Like Occurrent? Star us on GitHub:

Note

Occurrent is in an early stage so APIs, and even the data model, are subject to change in the future.

Occurrent is an event sourcing library, or if you wish, a set of event sourcing utilities for the JVM, created by Johan Haleby. There are many options for doing event sourcing in Java already so why build another one? There are a few reasons for this besides the intrinsic joy of doing something yourself:

• You should be able to design your domain model without any dependencies to Occurrent or any other library. Your domain model can be expressed with pure functions that returns events. Use Occurrent to store these events. This is a very important design decision! Many people talk about doing this, but I find it rare in practice, and some existing event sourcing frameworks makes this difficult or non-idiomatic.

• Simple: Pick only the libraries you need, no need for an all or nothing solution. If you don’t need subscriptions, then don’t use them! Use the infrastructure that you already have and hook these into Occurrent.

• Occurrent is not a database by itself. The goal is to be a thin wrapper around existing commodity databases that you may already be familiar with.

• Events are stored in a standard format (cloud events). You decide how your domain events map to a CloudEvent, with a converter or by hand. While this may seem like a limitation at first, why not just serialize your POJO directly to arbitrary JSON like you’re used to?, it really enables a lot of use cases and peace of mind. For example:

  • It should be possible to hook in various standard components into Occurrent that understands cloud events. For example a component could visualize a distributed tracing graph from the cloud events if using the distributed tracing cloud event extension.
  • Since the current idea is to be as close as possible to the specification even in the database,
    you can use the database to your advantage. For example, you can create custom indexes used for fast and fully consistent domain queries directly on an event stream (or even multiple streams).

• Composable: Function composition and pipes are encouraged. For example pipe the event stream to a rehydration function (any function that converts a stream of events to current state) before calling your domain model.

• Pragmatic: Need consistent projections? You can decide to write projections and events transactionally using tools you already know (such as Spring @Transactional)!

• Interoperable/Portable: Cloud events is a CNCF specification for describing event data in a common way. CloudEvents seeks to dramatically simplify event declaration and delivery across services, platforms, and beyond!

• Use the Occurrent components as lego bricks to compose your own pipelines. Components are designed to be small so that you should be able to re-write them tailored to your own needs if required. Missing a component? You should be able to write one yourself and hook into the rest of the eco-system. Write your own problem/domain specific layer on-top of Occurrent, see How Occurrent is Layered.