Identity Groups on the Query Side (CQRS)

Background

In a CQRS system (command-query responsibility separation) that is based on top of event sourcing, we have the need to run a query for a given set of unique aggregate identifiers.

For example, if we have a banking system, our aggregate might be "bank account" which is uniquely identified by an account number.

We can create projections that run over one account number and return a value by interacting with the events in the event stream for that aggregate and by performing operations on the data in those events can arrive at a current state for the aggregate identifier. In the bank account example, events like [Interest Paid] and [Deposit Paid In] would increment the running balance of our running balance projection, and events like [Withdrawal] and [Charge Paid] would reduce that balance.

However when running queries against a system, we often want to restrict the set of aggregate unique identifiers over which the projection is run (both from a performance point of view but also from a business need point of view, we don't always want to query every single aggregate).

In our bank account example, we might want a group of account numbers that is identified by the group named "Held by US citizens" if we were going to perform some form of statutory tax reporting.

Identity Groups

Identity groups are a way of creating (and maintaining) a list of unique identifiers that share a common attribute or business meaning. These groups are maintained separate to the aggregate identifier themselves - i.e., it is not up to the aggregate to hold information as to whether it is considered in or out of any given group but rather the group itself must test the aggregate identifiers and count them in or out.

This maintenance of the identity group is itself a projection over the event stream. This, in turn, means that it is possible to regenerate the group at a specific point in time as well as evaluating membership of the group now. For our hypothetical business need above it might be that tax reporting is required for accounts held by US citizens as at the start of the tax year only - which means we need to run our group projection up to that date to generate the set of accounts over which we will run our taxation reporting projection.

Restrictions

Since we want to be able to refer to a group when initiating a query but don't want to have to evaluate the group every time we need to have each group having its own unique name (for any given aggregation).

An identity group can only apply to one type of aggregation.

Built-in Groups

There are two built-in groups that can be created for every aggregate identifier. The "instance" group contains one and only one specified instance of the aggregate identifier and the "all" group contains all the recorded instances of an aggregate (effectively all the event streams created for that aggregate identifier).