NEventStore is a very powerful library that works very well in ES context. That’s its definition:

NEventStore is a persistence library used to abstract different storage implementations when using event sourcing as storage mechanism. This library is developed with a specific focus on DDD/CQRS applications

There are some interesting point using an event store like NEventStore:

  • It’s an append-only event store: that means that
you will never add, alter or remove an event. So if you suddenly end up with a bug in your system which is generating wrong events, then the only way for you to correct this is to generate a new compensating event correcting the results of the bug. Of course you want to fix the bug as well. This way you have also tracked when the bug was fixed and when the effects of the bug where corrected
Mark Nijhof

.

  • Logs everything happened:
By having this architecture we now basically solved the problem of loosing original intent, because we keep all events that have ever happened and these evens are intent revealing. An other very interesting thing is that now you have an audit log for free, because nothing will ever change state without an event and the events are stored and used in building up the Aggregate Roots they are guaranteed in sync with each other
Mark.Nijhof
  • Give us a Write-only Domain Store:
the repository only has to be able to Get an Aggregate Root by its Id and it must be able to save the generated events. You also completely get rid of any impedance mismatch between the domain and the persistence layer
Mark.Nijhof
  • Snapshooting:
So what happens when you have 100.000 events that need to be replayed every-time you load the Aggregate Root, that will slow down your system immensely. So to counter this effect you would use the Memento pattern to take a snapshot from the internal state of the Aggregate root every x number of events. Then the repository will first request the snapshot, load that in the Aggregate Root and then request all the events that have occurred after the snapshot, bringing it back to the original state. This is only an optimization technique you would not delete events that happened before the snapshot, that would pretty much defeat the purpose of this architecture
Mark.Nijhof

and

Snapshots should generally be taken "out of band"--that is out of the mainline of processing. In other words, when a series of events are being committed, you don't want to take a snapshot at that point. Instead, you'll want to have another thread or process take a snapshot asynchronously
Jonathan Oliver

Comments

You May Also Enjoy