13

I was asked to do some exploration in event sourcing. my objective is to create a tiny API layer that satisfies all the traditional CRUD operation. I am now using a package called 'sourced' and trying to play around with it (Using Nodejs).

However, I came to realize that the event sourcing is not quite useful when it is used alone. usually, it is coupled with CQRS.

My understanding of the CQRS is, when the UI sends a write command to the server. the app does some validation towards the data. and saves it in the event store(I am using mongoDB), for example: here is what my event store should look like:

{method:"createAccount",name:"user1", account:1}
{method:"deposit",name:"user1",account: 1 , amount:100}
{method:"deposit",name:"user1",account: 1 , amount:100}
{method:"deposit",name:"user1",account: 1 , amount:100}
{method:"withdraw",name:"user1",account1,amount:250}

It contains all the audit information rather than the eventual status. however, I am confused how can I handle the read operation. what if I want to read the balance of an account. what exactly will happen? here are my questions:

  1. If we can not query the event store(database) directly for reading operation, then where should we query? should it be a cache in memory?
  2. If we query the memory. is the eventual status already there or I have to do a replay (or left-fold) operation to calculate the result. for example, the balance of the account 1 is 50.
  3. I found some bloggers talked about 'subscribe' or 'broadcast'. what are they and broadcast to who?

I will be really appreciated for any suggestion and please corret me if my understanding is wrong.

Ruben Bartelink
  • 59,778
  • 26
  • 187
  • 249
nick
  • 460
  • 4
  • 24
  • 1
    For me, one concept you don't surface awareness of in your question is the fact that events are normally maintained in streams, which are segregated per Aggregate in the DDD sense. The seqs of events that are considered in a decision process are limited to those you colocated when writing. On the querying side, you can in some low load cases hack it by reading+folding the full stream. In general, as the answers allude to, projections is how the equivalent of querying is achieved. The [intro docs for GES](http://docs.geteventstore.com/introduction/4.0.2/event-sourcing-basics/) are a good read – Ruben Bartelink Sep 04 '17 at 12:59
  • 1
    @RubenBartelink yes you are right! I have no idea about how to use the events streams. I should look into the stream maintenance things. Thanks for your suggestion! – nick Sep 06 '17 at 03:50

2 Answers2

10

Great question Nick. The concept you are missing is 'Projections'. When an event is persisted you then broadcast the event. You projection code listens for specific events and then do things like update and create a 'read model'. The read model is a version of the end state (usually persisted but can be done in memory).

The nice thing is that you can highly optimise these read models for reading. Say goodbye to complicated and inefficient joins etc.

Becuase the read model is not the source of truth and it is designed specifically for reading, it is ok to have data duplication in it. Just make sure you manage it when appropriate events are received.

For more info check out these articles:

Hope you find these useful.

** The diagram refers to denormalisation where it should be talking about projections.

Codescribler
  • 2,235
  • 18
  • 22
  • Your answer wiped my confusion! thanks a lot! I am now implementing a small bank deposit/ withdraw application. after the event was committed. I broadcast this event ('deposit' for example ), and the corresponding part who is listening to the 'deposit' will handle this deposit event to update the balance. Is this correct? – nick Sep 06 '17 at 03:54
  • And by the way, let's assume I have millions of record in the database. is that mean if I restart the server. it could take a while to initialize the ReadModel to be updated? – nick Sep 06 '17 at 07:19
  • 1
    Almost on your first comment. Make a difference in the way you name commands and events. Commands are in the imperative and events are always in the past tense. Regarding re-initialisation. Restarting the app should take no longer than any other app. You should persist the read model. Hope that makes sense. – Codescribler Sep 06 '17 at 13:30
4

You can query the event store. The actual method of querying is specific to every implementation but in general you can poll for events or subscribe and be notified when a new event is persisted.

The event store is just a persistence for the write side that guaranties a strong consistency for the write operations and an eventual consistency for the read operations. In order to "understand" something from the events you need to project those events to a read-model then query the read-model. For example you can have a read-model that contain the current balance for every account as a MongoDB collection.

Constantin Galbenu
  • 16,951
  • 3
  • 38
  • 54
  • 1
    Thanks! your answer helped me to understand it! I am now implementing the broadcast to the listeners, then the listener can handle the corresponding methods (for example, 'withdraw') – nick Sep 06 '17 at 03:57