Event sourcing infrastructure implementation

Question

I implement Event Sourcing and CQRS pattern in my application. I inspired by CQRS journey where I downloaded sample code. There I found whole infrastructure for Event sourcing (CommandHandlers, EventHandlers, Events, Envelopes ... etc.), but it is quite big amount of code and I can't imagine that I need all of code for my simple Event sourcing.

Do you know some common tested library/nuget package/project containing all infrastructure for sending/registering commands, events and everything what I need in Event sourcing pattern? Or should I implement it by myself?

Answer 1

May I introduce this .NET Core 2.x based event sourcing framework: https://github.com/jacqueskang/EventSourcing/

It provides base classes for implementing events, event-sourced entities, entity repositories, and several simple event stores to persist events in text file or in database (using EF Core).

It's especially easy to be integrated in a ASP.NET Core web application, I have a pretty simple demo here.

Welcome any contribution or comments!

Answer 2

The general recommendation is to not write your own event store. Sure, you can write your own ES, but do it only for educational purposes. For production systems I would recommend you to use an existing ES. It might look like a lot of unnecessary infrastructure code at first but you will soon notice that you do need it. In its simplest form ES is not that hard but once you start dealing with concurrency, performance etc it will be more complicated.

NEventStore and Event Store are two well known event stores.

As a side note from my own experience, do not underestimate the time that you will need to invest on infrastructure code even if you use an existing ES.

Answer 3

Greg young has created a really simple CQRS/ES project that you can use as a starting point. The infrastructure is much simpler than the CQRS journey code

https://github.com/gregoryyoung/m-r

Answer 4

I've recently open sourced my Java implementation of an event sourcing (database) framework, Eventsourcing for Java. However, the plan is to have multiple language implementations down the road, including .NET. That's why there's an ongoing effort to specify the fundamentals.

My implementation is focused more on the faithful command/event capture with a lazy "read side" rather than pro-active application of every event.

Answer 5

I implemented my own event store - messaging solution based on CQRS Journey. The message persistence is on top of SQL Server. With it you can do a lot more: - You can subscribe at any time to a stream. Very useful when you need a new ViewModel for the read side. This will enable you to have high availability on the read side. - You can distribute your application in multiple nodes in a micro service fashion. - You can query your event store, like Greg Young´s event store. - And a lot more...