was reading some interesting stuff on event sourcing katas in Java 22 and was thinking about doing it in clojure and just wondering what the differences might be and whether or not I'd use core.async/atoms/external db or queue or other

It's fun to event source over something reducible. Clojure fits this quite nicely

> event sourcing katas in Java 22 sounds like a fun read

https://event-driven.io/en/this_is_not_your_uncle_java/ was the post

And, yeah, event sourcing is just the result of a reduce on the events

I think

I had fun one evening turning on all experimental features and trying to implement Monads with Java to make everyone angry 😅

The big government project I used to work on with @U0AQ3HP9U and @U054UD60U uses event sourcing and CQRS. We had a pretty bespoke solution, but it worked pretty well as far as I can remember. It's been more than 4 years since I left, though.

The thing I remember the most is having a huge layer between the data store and the application later to apply sequential transformations to events since the underlying data model changed many times during the development phase.

So events over time persisted in various states of the ever changing data model.

Cough cough…. Apache Pulsar 😉

I was looking at event sourcing on and off when exploring the world of offline-first and p2p systems. I came to the conclusion that for a decentralized p2p system you eventually need an event bases system to reason about the intention of the contributor.

I think offline first P2P needs CRDTs instead. I've been thinking about that with LoRa and mesh networking

A long time ago with @U09N5N31T , @U1AS6PFGX we did https://github.com/rill-event-sourcing/rill and used it in production for a few years before the company pivoted and the clojure software was scrapped. A few billion events, and a fun architecture

In a subsequent project we did another take on it, with https://github.com/rill-event-sourcing/wheel 😄

Nowadays with the folks of Nextjournal (cc @U5H74UNSF) we're not far away from it architecture-wise, but not a strict event-sourcing with CQRS as those two projects. 😄

We too. As @U0AD3JSHL said we did a bunch of fairly “pure” event sourcing projects and it does have a few nice advantages. Looking back I’d probably do something a little less pure and take more advantages of existing database engines

@U09N5N31T existing database engines like postgres or other?

For a project with nextjournal we're using datomic and for some parts of the application we're not doing event-sourcing, so regular datomic stuff applies, and for other parts we're saving 'events' as simpler datomic entities.

One thing @U4P4NREBY's anecdote reminds me - even sourcing without generational versioning is a recipe for pain (then your reader just promotes old generations on read, it's fun, building a ladder)

I don't remember how it worked but there are two ways, right? 1. convert old events to the new version on read from event store 2. make your processors handle old and new events.

Not sure what is worst, maybe it's a solid "it depends"

We did 1

I wonder how to take into account missing information which would require access to other entities / the current state?

We apply brain mass whenever considering to promote old stuff. If data is missing, can't be done, create a new event type instead.

As faulty a process as any other where brain mass is applied 😊

@U0525KG62 Both regular relational/sql databases like Postgres and in memory databases like datascript. I think we underestimated the challenges of projecting events to entities and doing queries on entities/relations.

A lot of challenges where underestimated 😛