This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

FAQ

Frequently asked questions.

Find answers to most common questions here.

1 - Compatibility

Platforms and SDKs

Only .NET 5+? Why not .NET Framework 3.5?

Eventuous uses the latest features of C#, like records and advanced pattern matching. Therefore, we rely on compiler versions, which support C# 9.

We also aim to support the current application hosting model that only got consistent and stable in .NET 5.

Eventuous supports .NET Core 3.1, but it’s not a priority. Some packages only support .NET 6 as they need the latest features like minimal API. Right now, Eventuous provides packages for the following runtimes:

  • .NET Core 3.1
  • .NET 5
  • .NET 6

Targets will be added and removed when getting our of support or when new versions get released.

2 - Compare

How Eventuous is different from others?

EventFlow

EventFlow is probably the most popular Event Sourcing and CQRS framework for .NET. It has a rich history, it’s battle-tested and ready for production use. So, why not EventFlow?

Abstractions

EventFlow is full of abstractions. There’s an interface for everything, including commands and events. In fact, Eventuous discourages you to use interfaces for these primitives, as they are just serializable property bags. For example, a Command base class in EventFlow has 60 lines of code with three constrained generic parameters, one inheritance (ValueObject), and it implements a generic interface ICommand. In Eventuous, we recommend using records, but you can use classes too.

Codebase size

We strongly believe in code, which fits in one’s head. You can read all the Eventuous core library code in half an hour and understand what it does. There is no magic there. EventFlow, on the other side, has lots of interfaces and attributes that aim to prevent developers from doing the wrong thing. All those guide rails need code, which Eventuous doesn’t have and will never have.

Just enough

Unlike EventFlow, we don’t provide anything special for logging, DI containers, scheduled jobs, sagas, etc. We know some open-source great tools to deal with these concerns, which are out of scope for this project. However, Eventuous plays well the any DI, as well as it uses Microsoft logging abstractions.

3 - Persistence

What about repositories and other questions about persistence

Why you don’t have repositories?

The definition of the Repository pattern from bliki:

[Repository] Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.

When using Event Sourcing, the idea of having a collection-like interface for accessing domain objects might be challenging to implement. It’s because we don’t persist domain objects state, but their state transitions as events instead. Therefore, having a collection-like abstraction on top of an event-sourced persistence would require, essentially, to load the whole event store to memory.

As Event Sourcing greatly benefits from using CQRS, the need to have a collection-like persistence abstraction also diminishes. In the command-oriented flow, you would only change the state of a single aggregate by handling one command. Therefore, you neither need a collection-like interface to load the state of a single aggregate, nor to append new events for a single aggregate to the store.