Event-driven architecture and structure of events

Name the event "CustomerUpdate"

First let's start with your event name. The purpose of an event is to describe something which has already happenned. This is different from a command, which is to issue an instruction for something yet to happen.

Your event name "CustomerUpdate" sounds ambiguous in this respect, as it could be describing something in the past or something in the future.

CustomerUpdated would be better, but even then, Updated is another ambiguous term, and is nonspecific in a business context. Why was the customer updated in this instance? Was it because they changed their payment details? Moved home? Were they upgraded from silver to gold status? Events can be made as specific as needed.

This may seem at first to be overthinking, but event naming becomes especially relevant as you remove data and context from the event payload, moving more toward skinny events (the "option 3" from your question, which I discuss below).

That is not to suggest that it is always appropriate to define events at this level of granularity, only that it is an avenue which is open to you early on in the project which may pay dividends later on (or may swamp you with thousands of event types).

Going back to your actual question, let's take each of your options in turn:

Name the event "CustomerUpdate" and include all information (updated or not) about the customer

Let's call this "pattern" the Fat message.

Fat messages (also called snapshots) represent the state of the described entity at a given point in time with all the event context present in the payload. They are interesting because the message itself represents the contract between service and consumer. They can be used for communicating changes of state between business domains, where it may be preferred that all event context be present during message processing by the consumer.

Advantages:

• Self consistent - can be consumed entirely without knowledge of other systems.
• Simple to consume (upsert).

Disadvantages:

• Brittle - the contract between service and consumer is coupled to the message itself.
• Easy to overwrite current data with old data if messages arrive in the wrong order (hint: you can mitigate this by using the event sourcing pattern)
• Large.

Name the event "CustomerUpdate" and include only information that have really been updated

Let's call this pattern the Delta message.

Deltas are similar to fat messages in many ways, though they are generally more complex to generate and consume. A good example here is the JSONPatch standard.

Because they are only a partial description of the event entity, deltas also come with a built-in assumption that the consumer knows something about the event being described. For this reason they may be less suitable for sending outside a business domain, where the event entity may not be well known.

Deltas really shine when synchronising data between systems sharing the same entity model, ideally persisted in non-relational storage (eg, no-sql). In this instance an entity can be retrieved, the delta applied, and then persisted again with minimal effort.

Advantages:

• Smaller than Fat messages
• Excels in use cases involving shared entity models
• Portable (if based on a standard such as jsonpatch, or to a lesser extent, diffgram)

Disadvantages:

• Similar to the Fat message, assumes complete knowledge of the data entity.
• Easy to overwrite current data with old data.
• Complex to generate and consume (except for specific use cases)

Name the event "CustomerUpdate" and include minimum information (Identifier) and/or a URI to let the consumer retrieves information about this Customer.

Let's call this the Skinny message.

Skinny messages are different from the other message patterns you have defined, in that the service/consumer contract is no longer explicit in the message, but implied in that at some later time the consumer will retrieve the event context. This decouples the contract and the message exchange, which is a good thing.

This may or may not lend itself well to cross-business domain communication of events, depending on how your enterprise is set up. Because the event payload is so small (usually an ID with some headers), there is no context other than the name of the event on which the consumer can base processing decisions; therefore it becomes more important to make sure the event is named appropriately, especially if there are multiple ways a consumer could handle a CustomerUpdated message.

Additionally it may not be good practice to include an actual resource address in the event data - because events are things which have already happened, event messages are generally immutable and therefore any information in the event should be true forever in case the events need to be replayed. In this instance a resource address could easily become obsolete and events would not be re-playable.

Advantages:

• Decouples service contract from message.
• Information about the event contained in the event name.
• Naturally idempotent (with time-stamp).
• Generally tiny.
• Simple to generate and consume.

Disadvantages:

• Consumer must make additional call to retrieve event context - requires explicit knowledge of other systems.
• Event context may have become obsolete at the point where the consumer retrieves it, making this approach generally unsuitable for some real-time applications.

When raising an event, which pattern is the most suited?

I think the answer to this is: it depends on lots of things, and there is probably no one right answer.

Update from comments: Also worth reading, a very old, classic, blog post on messaging: https://docs.microsoft.com/en-gb/archive/blogs/nickmalik/killing-the-command-message-should-we-use-events-or-documents (also here: http://vanguardea.com/killing-the-command-message-should-we-use-events-or-documents/)

Martin Fowler gave a great talk about "The Many Meanings of Event-Driven Architecture" (the content is based on this paper) in which he mentioned the Event-Carried State Transfer pattern.

It seems to be close to your second option "Delta message" with the difference that it doesn't try to describe an entity, but instead describe a named business fact that happened and carry over all the necessary data to understand this fact.

I don't think it matters how you have modeled your persistence layer when it comes to designing domain events. Likewise, I don't think it matters how your consumer has modeled its own persistence layer when designing domain events.

Thus, I don't think it's wise to put as an advantage the fact that you can apply the event as a patch directly on your data (from a consumer point of view), because it pushes the producer to design their events given the persistence model of a consumer.

In that case, I would tend to think that you're designing persistence patches, instead of domain events.

What do you think?