You’re right. sorry for that.
I haven’t used any frameworks, but I have used GitHub - commanded/eventstore: Event store using PostgreSQL for persistence · GitHub in the past, and I’ve built a small eventstore library on top of sqlite which for works for my use cases but I’m not going to recommend it for general public use 
I don’t think I’m the intended audience for a library like Must. So not sure I’m going to be able to give you much feedback.
What bugs me most in all the implementations of ES so far, is the necessity to explicitly issue an event. All these MyEventStore.append_to_stream/3 in Commanded, or ChangeStore.save_change!/2 in Must, or anything else.
In persistomata I mentioned above I abstracted data and made each and every data change an event, that’s it. I strongly believe that ES had been invented to diminish a hassle about persistence, ideally to zero. I can live with @side_effect annotation, or @intermediate_store [target: :result], but explicit calls to functions exported from the store implementation ditch the purpose of ES completely IMHO. If I need to write a code keeping in mind that I have to store it here and there, I am good with Postgres, ain’t I?
I’m probably going offtopic to the original topic again, so @LostKobrakai feel free to split this up.
I can agree with the storing part, but not with the issuing an event.
I don’t think that was the original goal, but it might have been an intended side-effect.
But I don’t agree with some of the other things - or I’m misunderstanding stuff.
Emitting domain events allows you to very clearly and explicitly capture decisions made in a system / in a process and base your next decisions on the past ones.
# this is based on a real domain I worked in but hugely simplified
DocumentSubmittedForAproval
FourEyesApprovalRequested
DocumentReceivedApproval(person1)
DocumentReceivedApproval(person2)
DocumentApproved
# Now something changes and the rules is that after a change we need 1 of the
# initial pair of 4 eyes to take another look - in reality it depends on the type of change.
DocumentChanged
NewApprovalRequestedFrom(person1 or person2)
DocumentRecievedApproval(person 1)
DocumentApproved
In reality a document consists of multiple lines and each line has specific approval rules on changing things sometimes only the one line needs to be re-approved, sometimes mutliple.
Modelling this on top of a regular postgres state based system is possible, but with a stream of events it really tells the story of what happened to this document and what is allowed to happen right now.
So the choice of emitting an event is really valuable - again - it explicitly captures the domain/business decision.
Sure. I cannot agree more.
But if you think about this in a more abstract way, how often do you want to capture the domain/business decision without amending any data? What kind of a business decision is not mirrored by any data change, leaving the whole system in the state which cannot be distinguished from the state before this decision?
This is to be handled by an FSM instance, it has nothing to do with the ES per se. Add listeners to data changes and make one of these listeners writing to ES—and you are all set. You code the business logic, and ES happens to appear automagically. Alongside with materialized views in ClickHouse—you get the latest snapshot, the full events history, and whatnot. The consistency of business processes is guaranteed by an FSM. Voilà.