CQRS: Should I keep appending events?

Question

Let's say I have an operation in my system that will set a users email, what shall happen if I set the same email multiple times from an CQRS and event sourcing perspective?

Only once:

CustomerContactInformationSetEvent

Or, keep appending:

CustomerContactInformationSetEvent

CustomerContactInformationSetEvent

CustomerContactInformationSetEvent

CustomerContactInformationSetEvent

Answer 1

The operation issues a SetCustomerContactInformation command.

In most situations, if the new information already matches, it does not record a new CustomerContactInformationSetEvent event.

If the above arrangement loses information that is important in your domain, adjust as necessary. I assume an event sourcing setup in which event order is known.

Answer 2

Let's say I have an operation in my system that will set a users email, what shall happen if I set the same email multiple times from an CQRS and event sourcing perspective?

In most cases, you'll want the domain model to be an Idempotent Receiver; multiple copies of the same message should have no observable effect.

In terms of what you will see in the event history, you might see any of the following approaches:

A single event in the journal, representing the point when the message was set to the new value, and no further entries when duplicates of the message first appears. The model didn't change, after all, so we don't need to create a representation of the change in history.

Multiple events in the journal: there's nothing conceptually wrong with capturing redundant events - the next version of the model may not actually consider those events to be redundant, so capturing them explicitly may yield additional business value later.

Multiple journals: one journal documenting all of the incoming messages (ie, the write ahead log), and a separate journal with a single event describing the change of state.

The first approach is probably the most common. Recording many events can be important when events can arrive out of order.

ChangeEmail: bob@example.org
ChangeEmail: alice@example.org
ChangeEmail: bob@example.org

To know the correct email address, you probably need to know the order of these changes, which isn't necessarily the order in which they arrived.

Compare

ChangeEmail: bob@example.org    time:1200
ChangeEmail: alice@example.org  time:1300
ChangeEmail: bob@example.org    time:1200

with

ChangeEmail: bob@example.org    time:1200
ChangeEmail: alice@example.org  time:1300
ChangeEmail: bob@example.org    time:1400

and

ChangeEmail: bob@example.org    time:1200
ChangeEmail: bob@example.org    time:1400
ChangeEmail: alice@example.org  time:1300