eugene-khyst / postgresql-event-sourcing Goto Github PK

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

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'
            }
        }
    }
}

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?

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.

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.

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.

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.

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