CODEWITHSUNDEEP
messagingevent-sourcing
randomsolutions
randomsolutions

Reputation: 2273

Message Format In Event Based System

I'm trying to get a handle on best practices around defining a message, and I have a few high-level questions.

  1. It seems like all our consumers need different aspects of a message. Does that mean message formats just end up being a union of everything each distributed system needs?
  2. Without knowing all my consumers, how do I know what to put in a message?
  3. Are there any best practices to help determine if I need messages that are close to what my table looks like vs. a higher level message? It seems like whenever I define a message, it's really closely tied to my database schema.

Upvotes: 0

Views: 205

Answers (2)

Constantin Galbenu
Constantin Galbenu

Reputation: 17683

In Event sourcing the domain events are persisted instead of the entire state. So the domain events contain all the information needed to reconstruct the correct state. This means that you design your domain events to clearly, completely and correctly express a fact that has happened.

The safest thing is too put in the events only what is strictly necessary for the state to be reconstructed and nothing more. If you design the events correctly (according to the domain), then all the subscribers could project any valid possible state (from the domain point of view), most probably by subscribing to multiple event streams. The simpler the events the more streams need to be subscribed to but this is OK.

Upvotes: 1

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57279

Greg Young's book Versioning in an Event Sourced System was a big help to me in getting my head around messages.

It seems like all our consumers need different aspects of a message. Does that mean message formats just end up being a union of everything each distributed system needs?

It often means finer grain messages, with subscribers being more discriminating about what messages they review.

Without knowing all my consumers, how do I know what to put in a message?

Especially when you aren't sure what to put in the message, concentrate on designing schemas that can evolve safely.

Are there any best practices to help determine if I need messages that are close to what my table looks like vs. a higher level message? It seems like whenever I define a message, it's really closely tied to my database schema.

It's not entirely coincidence. If you squint and apply a bit of imagination, you might notice that events are messages from one system to another, where persistence is a message from a past version of a system to the present.

So it isn't entirely shocking that there are similarities.

One reason to be careful is that an individual service can change its persisted representations easily, since it is the only client. But changing a message between services requires extra care if the publisher and all of the subscribers need to be updated. Messages that cross deployment boundaries generally need more stable schemas than those used within a single deployment unit.

Upvotes: 2

Related Questions