eugene-khyst/postgresql-event-sourcing

A reference implementation of an event-sourced system that uses PostgreSQL as an event store built with Spring Boot. Fork the repository and use it as a template for your projects. Or clone the repository and run end-to-end tests to see how everything works together.

Hi there 👋

My name is Eugene Khyst. I am a Principal Software Engineer and Software Architect and creator of ArtistAssistApp - the best painting and drawing assistant app 🎨🖌️

Favorite tech stack

Favorite methodologies

postgresql-event-sourcing's Issues

Separate ES-related infrastructure code from application code

Currently the application code is entangled with the generic ES-related infrastructure code, e.g. the enums EventType and AggregateType are pulling-in domain-specific code into the generic EventRegistryand AggregateRegistry implementations.

For a simple example this is ok, but for a template of a production-grade application this could be improved - maybe by aligning to the architecture approach of Clean Architecture (as Tom Hombergs describes it in his blog post Hexagonal Architecture with Java and Spring and his book Get Your Hands Dirty on Clean Architecture ).

So I would like to suggest refactoring the ES-related infrastructure code from the application into it's own package or module.

Build Spring Boot image for arm64 architecture

In case someone is running this project on a M1/M2 Apple chip, this will enable building the image for the correct architecture:

Replace the jib configuration from the build.gradle file from event-sourcing-app with:

jib {
    to {
        image = "eugene-khyst/postgresql-event-sourcing:${project.version}"
    }
    from {
        image = "eclipse-temurin:21-jre"
        platforms {
            platform {
                architecture = 'arm64'
                os = 'linux'
            }
        }
    }
}

Does this work with two writers?

Let's say I have two instances of the service. Both services are creating events. When using postgres, it's possible for there to be gaps in the bigserial id used for the event table.

For example, it's possible for there to be visible id's 0, 1, 3, 4, 5 while the other service is still in the process of getting an event committed with id 2.

Postgres does not support subscribing on changes?

How about:

https://www.postgresql.org/docs/current/sql-notify.html

?

When NOTIFY is used to signal the occurrence of changes to a particular table, a useful programming technique is to put the NOTIFY in a statement trigger that is triggered by table updates. In this way, notification happens automatically when the table is changed, and the application programmer cannot accidentally forget to do it.

Column outbox.last_id should be BigInt not Int4

Not a real issue for this demo, but I think it should reflect the type of event.id bigserial.

Great samples and blogs btw. Thank you.

My project may also be interesting

Hi,

first of all, awesome work :-)

couldn't find your e-mail address, but I'm working on a (bi)temporal DBS[1] in my spare time, which basically also tracks changes and stores the results of CRUD operations, creating new revisions on each trx commit by appending data to an indexed log (thus, also no WAL is needed -- also due to the limitation of a singe writer per resource).

It avoids long chains of having to apply incremental deltas with intermittant snapshots through a sliding snapshot algorithm.

You can't alter the history, but of course revert to an old revision, add commit messages, track changes to specific nodes or even subtrees, as it optionally stores a rolling hash...

Thought since a couple of years, that it kind of brings temporal "tables" (binary JSON resources actually) and event stores one step closer.

Kind regards and a nice week
Johannes

[1] https://github.com/sirixdb/sirix | https://sirix.io | https://sirix.io/docs/concepts.html

Adopt aspects from Eventuous (The Right Way)

I really like your fully end-to-end approach with its thorough design and documentation. Great work.

But I would love to see in your solution the adoption of some aspects of Alexey Zimarevs The Right Way and its C# library Eventuous, e.g.

• Separation of (immutable) state management usable without aggregates
  • Required for getting rid of aggregates (behaviour) from the core of a generic ES implementation
• Support for functional domain models and functional services by using isolated lambdas instead of state mutation within aggregates
  • Functional programming helps in managing side effects, e.g. due to state mutations within multi-threaded applications
• Event Store support for real-time subscriptions usable for projecting read models or publishing integration events
  • For the (in Java land) missing C# (and go-lang) construct of Channels the Java-based CSP (Communicating Sequential Processes) implementation JCSP can be used

How to handle incomming integration events?

Thank you very much @eugene-khyst ! Especially the paragraph about Domain events vs Integration events was an eye-opener.

I am currently wondering how replaying of events works and how the system state can be reliably recreated (conceptually). A reason to do that might be an added or modified projection (e.g. to add another column in a table providing extra information which can be extrapolated from existing events).

This seems to be strait forward when only internal domain events contribute to the aggregate's state. We simply drop the table(s) belonging to the projection, then pipe all historic events through the new/changed event handler of the projection and finally continue to feed new events synchronously.

But, can't we also have aggregates that perform state changes due to incoming integration events? (I am unsure if this is conceptually correct.)

How would we deal with incoming integration events in this case? In order to be able to replay events later, it seems to me, that the incoming events need to be enqueued into the event store along with the internal domain events, because only then we are able to preserve their exact order of processing relative to the internal events.

So in this case we had some process receiving incoming integration events. First, it sticks them into the event store (while dropping repeatedly delivered events). Then it hands them over to synchronous event processing (but not asynchronous forwarding). Finally, it acknowledges the reception to the event broker.

Does this sound valid or is there a better pattern? I am thankful for every comment.

Still can not image how Read Model can be implement from Order Projection

Hi, Your template was very helpful in illustrating how event sourcing works in an order life cycle. Could you provide some examples using code or explain how a List can function as a projector in real life scenarios?