I'm trying to get a handle on best practices around defining a message, and I have a few high-level questions.
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.