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’ll bite
The short answer:
In a regular system every time something happens, a decision is made, we mutate the current state of the system - we update a table in a database.
In an eventsourced system we don’t mutate the state, instead we are going to store the decisions as events in an append only event store.

A bit more context - on my phone so I’ll keep it brief:

• when we need to make a new decision we read back the history of events to build the current state and then we can make a new decision in the form of events.
• events should preferably be domain events - not technical events. They have a meaning in the domain: Invoice marked as payed over invoice updated. Or user registered over user added.
• eventsourcing are more useful in domains where the passage of time matters

A CQRS explanation can follow when I’m at my pc.

Aren’t aggregates periodic snapshots of the state resulting from all the accumulated events ?

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.

First of all, aggregates is an overloaded term and I don’t use the definition both of you are pointing to - but that’s a different concern - I gave a full talk on this: https://www.youtube.com/watch?v=m7SMk8VA7Bg&t=3s

But even what you’re saying in the more traditional use of what an aggregate is, I don’t agree with what you’re saying.
In most event sourcing context, an aggregate just refers to the history of events for 1 specific stream. A stream might be a “bank account” or “the lifecycle of 1 invoice” or anything else that you decide to give an id.
That’s it. The periodic snapshots is purely an implementation detail - one that I would not recommend reaching for from the beginning.
So the aggregate is the history of events for a stream - so a list of events - the snapshot is something you can but don’t have to keep.

I was not trolling so I don’t think you are biting a bait. I am simply disillusioned by CQRS / Event sourcing is all, and I was honest enough to admit that at one point I stopped looking for good material.

Which means that material might very well exist today – and your material might be that, even – but I simply lost interest with the years.

Everything has an impl detail behind it. Ignoring those means exactly falling in the overly academic and theoretical trap I pointed at above. I want to know how is it done and why is this useful. Both are important. Helps a pragmatic doer like myself grok it.

I get the stated benefits but until somebody writes a library (thanks @LostKobrakai for the reference; fable still managed to confuse me almost at the beginning with “routers” and “oh, we need access to private functions so we do this thing” but still appreciate the pointer; /CC @benwilson512 as he’s the author) whose benefits are blindingly obvious at the literal first minute of reading, for now I’ll skip and will continue doing my own half-baked CQRS.

Bookmarked your video. It piqued my curiosity.

I had a plan to publish it with the comprehensive description, but I have negative bandwidth last year.

GitHub - am-kantox/persistomata: The event log framework, ready to use with Redis, Clickhouse, RabbitMQ, and PostgreSQL · GitHub is an example of how to build the app solely on EventSourcing (I have no weird idea anybody would look through that code though.)

The main idea is Clickhouse’s materialized views play the role of a snapshot, so basically the latest actual state is maintained by Clickhouse itself, the app just pushes new records there.

Good feedback. For Must, I am willing to use a different vocabulary for ES/CQRS concepts. The jargon was a big hurdle at first, so I’ll consider a different term for the command concept. Perhaps “change” is a more ubiquitous word.

I can see Fable’s value in brownfield CRUD applications and for anyone new to Event Sourcing. It looks like a nice way to layer in events without prior experience. As a contributor to that repo, it makes sense you have a story to tell about events.

Must is also an opportunity to try out newer concepts like the dynamic consistency boundary. This discussion from some of the ES influencers/thought leaders makes me think there is promise to this approach, and I hope to avoid aggregates entirely if this truly works.

This is how I currently expect commands/changes to flow into the system, using Must.process_command/2:

So far, there are two protocols and a planned behaviour for event storage. I expect the package to include adapter modules for the most common dependencies, perhaps Postgres & TigerBeetle as @dimitarvp mentioned.

@mudasobwa I was introduced to ClickHouse in the last year, and it dose sound like a good fit for an event store. Thanks for sharing!

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

@tcoopman Thanks for jumping in.

The intent for this thread is to focus on the ideas presented in Must to distill event sourcing concepts into a small extensible package. The discussion about aggregates, CQRS, and the like are valuable, but a bit out of the intended scope. A discussion about aggregates, using that talk as a starting point, deserves its own thread.

To reorient the conversation, I am curious which framework(s) and tools you use to implement Event Sourcing. Commanded, Fable, something bespoke?