15

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?

Shivprasad Koirala
  • 27,644
  • 7
  • 84
  • 73
y0j0
  • 3,369
  • 5
  • 31
  • 52

5 Answers5

17

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!

Jacques Kang
  • 728
  • 7
  • 3
  • 4
    Hey Jacques, I'm not sure why there's no reaction to your answer, but I looked at your code, and I REALLY enjoyed it. It's, in my opinion, very clean and very well written. Great job! – Farzad Jan 23 '19 at 05:53
10

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.

user707727
  • 1,287
  • 7
  • 16
  • Thank you. As I saw NEventStore is mostly package to store events somehow. But what I need is messaging infrastructure to send commands and events, to handle commands, events, to subscribe to events etc. Is it possible with NEventSore as well or you are using some another package for it? – y0j0 Jul 19 '15 at 09:37
  • 2
    @y0io You can use a service bus for that. There are a number of them (NServiceBus, Mass Transit etc), I have my own that I use. – MikeSW Jul 19 '15 at 17:00
  • 2
    @y0io You can take a look at NEventStore CommonDomain. That will give you some help but it will not help you with the messaging infrastructure. Still, you probably want to write that stuff yourself so that you will have control over it. For the projections check out the PollingClient in NEventStore. – user707727 Jul 19 '15 at 21:14
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

  • thanks a lot. Yes CQRS journey code is quite complex. Did you use code from Greg Young or you implemented infrastructure by yourself? – y0j0 Jul 18 '15 at 09:27
  • I used a simple implementation that I wrote myself, but it borrows heavily from that example. It really depends on how complex your application is. If you are just starting out, going with a full-fledged service bus might be overkill. –  Jul 20 '15 at 17:32
  • Yes, I share your opinion. Is is possible to extract from CQRS journey what you need or code it yourself. When application gets bigger and more complex something like NServiceBus is good choice. – y0j0 Jul 21 '15 at 07:20
  • NServiceBus has nothing to do with Event Sourcing. – Alexey Zimarev Jul 21 '15 at 08:27
1

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.

Yurii Rashkovskii
  • 1,122
  • 1
  • 10
  • 20
0

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...

Narvalex
  • 1,824
  • 2
  • 18
  • 27