Skip to content

Support for Events #62

@the-avid-engineer

Description

@the-avid-engineer

Is your feature request related to a problem? Please describe.
Commands are fundamentally ordered. It's very important that an entity built in the correct order because commands tend to affect the validity of other commands.

Events, on the other hand, shine best when they are used to communicate between different bounded contexts, and there are a few common "features" of using events this way:

  1. Out-of-order delivery
  2. At-least-once delivery (i.e., multiple deliveries are possible)

This would not only gear the EntityDb pack toward Event Sourcing, but also Event Driven Architecture.

Describe the solution you'd like
It may be beneficial to have a repository that can record events and not care about the order of events (concurrency is okay and tolerable) nor events that are delivered multiple times (duplicates will be ignored).

In addition to the abstraction solution, EventStore would be a good implementation candidate.

Additional context
Projections should not be restricted to reducing commands. It would be ideal if any source (Transaction, Communication) could be consumed. In order to achieve this, the IProjection<T> interface will likely break, bumping this to 10.0.0 milestone.

Much code related to transactions (ITransaction in the name) will need to be generalized to sources (ISource in the name)

Pending Question:

  1. Does EventStore throw an error if you send two events with the same event id to a single stream? Or does it just ignore the duplicate?

Metadata

Metadata

Labels

featureA feature has been requested

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions