It’s not really ready yet (a few upcoming changes in the pipeline), but GitHub - CargoSense/fable: Your events have a story to tell. · GitHub is a great intermediate between not doing es and going all in with commanded.

Thank you @LostKobrakai!
But I am searching for an ES project.
Just not a CQRS ES project - which divides the read from write interfaces.

You might like

I am not sure it is a requirement to have multiple database, isn’t it just a separation of concern between read and write?!

Thank you very much! @kokolegorille
I will watch it ASAP, it may provide me some clearance of what I am searching for.
Anyhow.
From my understanding -

Event sourcing is for each action happening in the system - It generates an event regarding this action.
the action is being stored and later on, you can do whatever you want with it. call the aggregator, or later on.
like Registry in elixir only here the data is saved to the event_store.

CQRS took it to another level which is optional. you have one logic for reading the information. and one logic to dispatching the data into the event_store/Database.

I want to keep my read and write logic under the same interface, including the validations, queries and so on.

If I am wrong, could anyone please clarify it for me?

Hi there, the problem that cqrs tries to solve is that because of the way data is written in the event store it’s very difficult and/or inefficient to do aggregate queries against that data.

For example lets say your domain is banking accounts, and each event represents a transaction in some customer’s account. Without a separate read model optimized for queries it would be really difficult to get stats like “give the top ten accounts that have made a deposit over x amount last month”

So unless you never read that data outside your main application (eg no admin screens presenting aggregate info over your data), you’re probably going to need a separate read model- and that means buying fully into es+cqrs

Event Sourcing

• Every software developer who has used version control has interacted with an Event Sourcing system.
• If you need to explain Event Sourcing to the business, use accounting ledgers.

@bottlenecked @peerreynders hank you very much for taking the time to respond.
@bottlenecked I agree when you see events as “actions”, then you generate the “new state of a different projection” by those actions.
I see events as changes in state of a model.
e.g. for bank - the transactions generate a new event in the balance_store - that includes all your balances from the open_account event.
the balance is transactions history. and the last state of the store is the current state.
anyhow I would like to save states instead of actions.

@peerreynders Thank you, I will check the sources out.
Thank you for reaching to me.

I see… so you’re thinking of capturing all current state in what is effectively a data dump. I think I can see a few problems with this approach:

• space efficiency: you’d need multiple times as much disk space to capture the entire state every time a change happens
• cpu cost: serializing the entire state to write to a database would be more costly than simply writing the action like ES canon suggests
• loss of clarity: one of the main benefits of event sourcing (if done right) is that a business user can just take a look at the actions performed in the order they occurred and get a clear picture of what exactly happened (events work as a log). To do that in the system you’re thinking of, one would have to diff between state captures to find out what happened

I hope the above help you

To be clear, Fable is ES, not CQRS, which is what I think @LostKobrakai meant to say. You could probably build a CQRS system on top of Fable, but that isn’t how we use it. Here’s a post where I talk about it in more detail: Opinion on file & memory based event sourcing system - #4 by benwilson512

You can use Commanded for event sourcing without requiring CQRS. Commanded focuses on the write model, but provides the Ecto projections library as one way of projecting events into a SQL database. There’s an undocumented function to access aggregate state (Commanded.Aggregates.Aggregate.aggregate_state/3) which would allow you to use Commanded with a single model for writing and to later query the state of the aggregate.

The reason why this isn’t the preferred approach (IMO) is because although the query model initially closely resembles the write model, soon they will start to differ in structure or access pattern (e.g. reporting, aggregating data and multi-entity views). Hence why I opt to go with separating reads from writes from the outset (CQRS) when using event sourcing.