To me GitHub - CargoSense/fable: Your events have a story to tell. · GitHub is still the most simple introduction one can have to event sourcing on elixir. It easily retrofits onto a regular ecto architecture, it’s 1000 loc you can read in like 15 minutes and most of it is simple boilerplate - if you can do phoenix with ecto you can understand the fable codebase. As with e.g. commanded you want to skip ProcessManager. Comparatively commanded feels like a kubernetes in terms of complexity in setup - useful, with lots of the mentioned sidequests.

I personally am a big fan of discovering concepts from first principle, so maybe that’s why I like the approach of fable so much. It shows you how to store decisions with events and updating an aggregate without needing to name those things. Once you got to see how such a system works then you can start giving the pieces names like the commands, aggregates, projections whatnot. Once the basic idea is explained you can start getting into all the additional ideas necessary to cover the sharp edges a more naive implementation might not care for or run into.

To turn this into the direction of Must. I like the idea of a more generalizable system, but it imo does suffer from e.g. expecting “Commands” where a user might not know what to make of the word command. At least for the context of teaching I’d personally stay with fable and maybe then update to Must if it eventually delivers a more featureful step beyond fable before needing to take the step to e.g. commanded.

This is way too true. In my entire career I’ve never once heard anyone explain it an approachable manner and at one point I stopped looking. It felt like Haskell fanatics explaining how monads are the Universe’s hidden ether essence.

I am not going to go question by question, just going to give you a high-level take: I work in finance. Having audit logs for pretty much anything is not just table stakes, it’s mandatory or you can get in a huge trouble; auditors don’t much care if you can’t explain $1.37 or $98700.62.

However, all the BS terms (sorry not sorry) like “aggregates” really don’t help.

As a start, I believe the whole thing should be very dev-centric i.e. “aggregates are periodic snapshots of all the accumulated events”. Friggin plain and simple, every good dev will get it immediately. (And I might have gotten the term and the explanation wrong which would be both funny and also prove my point perfectly.)

Storage adapters: TigerBeetle (financial ledger, might not apply to everything) and PostgreSQL. Rest can wait.

Approach is doomed to fail if it continues being snobby hand-wavy cult requiring too much homework from people who came to be sold on an idea. NOT to get a new university degree.

I know but it still triggered me a bit

I agree, and it’s something that is overlooked. But I do like to start at the why first. If we understand the why and can agree when it’s a good idea to use it, then we can have a look at how - which of course should be factored in the decision as well.
If the how is complex then even a good why might not be enough.

I think it’s also important to reflect on the fact that in essence eventsourcing is a different concept than state based systems. We often compare complexity against those systems that we already know and forget it took us (me at least) some time to learn those systems as well. So that means we should give it a fair chance (if the why matters to us).

I’m not going to explain the how here - Idon’t have time to do a decent explanation currently.
I’m also ignoring CQRS completely, I know, it just not that important for the essence of eventsourcing. I have some good diagrams on both of these things actually from courses that I gave in the past but I don’t have good written text. Maybe someday I’ll share that more broadly