Duncan Jones

(I fall back on banking examples but the "set based" question can arise in any domain - for example we might say "send out a lower price offer for anyone...

One way to approach this is to turn your group "where clause" into a conditional part of the command and to then run the command over every event stream (in...

Ideally a set-based "saga" command needs to be re-startable with every instance-level command being atomic. For example the bank's "Apply interest" command needs to store the "I applied interest to...

I have previously experimented with the concept of a **Classifier** which is simply a projection which can only return a boolean - i.e. is the event stream concerned part of...

Have got the idea of "Classification" (which is analogous to a projection which denotes WHERE clause membership) working so will do this as an experiment..

Another seemingly valid way to do set-like operations on the command side is to apply the command to every entity (in parrallel) with the command itself deciding if it is...

I take **correlation** to mean things belonging in the same group - I would tend to use this for events that were written in one process (or command handler) where...

To add complexity there are actually two versions of this uniqueness constraint in an event sourcing based system: unique as of now, and unique over all time. For some situations...

In both cases the **set of all identifiers used** needs to be kept as a cache or persisted read model, as running all the projections over all the streams to...

That would definitely work so long as the entire operation is wrapped in a lock or transaction. The most likely cause of non-uniqueness is the same command being picked up...