The Repository pattern is not naturally designed to be used in an event-sourcing context, given the nature of the event stream and aggregate models.

Anyway, a repository is intended to be a construct between a database and an application, to abstract access to the data through a common pattern: even-driven storage systems work with a different paradigm than the relational database system or the NoSQL systems, but they have an element in common, that is the object-centricity of the information (Entity and Agrgegate).

In an event-driven logic, the core element is the Event: the aggregation of a stream of events (identified by an arbitrary logic) makes an Aggregate, that presents the latest state of an Entity

Proposed Changes

We should try to pursue the implementation of a Repository that supports event-sourcing, working on the principles:

• Implementation of a base Aggregate contract that allows the aggregation of events to be persisted by the Repository
• The EventRepository retrieves the uncommitted events available from the Aggregate
• Definition of an AggregateKey construct that identifies the aggregate and its revision

Possible Limitations

Repositories that implement the support for event-sourcing might also be limited:

• A repository might not be dynamically queryable or filterable - Projectsions are constructs that require a pre-defined aggregation logic
• Listing the aggregates might be not possible - event streams are specific to a given entity, and data storage systems might not support retrieving events for more than one entity