You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Out-of-order delivery
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:
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?
The text was updated successfully, but these errors were encountered:
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:
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:
The text was updated successfully, but these errors were encountered: