Skip to content

Messaging

Message Sender: Who Sent the Command/Event?

When handling a message, regardless if it’s a command or event, you often want to know who sent the message. Who was the message sender? Not the service, but the actual user who initiated it. If it’s a command then who invoked it. If it’s an event, who invoked the command that changed state within the system that created the event. This post is in a series related to messaging. The overview is available in my Message Properties post. Authorization The most common reason for wanting to know who sent a message is to determine if they are authorized to… Read More »Message Sender: Who Sent the Command/Event?

Message-IDs for Handling Concurrency

This post serves as a guide for how you can use a Message identification (Message-IDs) on your messages (events and commands) to handle concurrency. This post is in a series related to messaging. The overview is available in my Message Properties post. YouTube If you haven’t already check out my YouTube channel. Message-IDs Each message, regardless of it being an event or a command, should contain a way to identify its specific instance of that message. This is as simple as adding a GUID/UUID to your messages: No other message (event/command) should ever use this ID (unless you’re also using… Read More »Message-IDs for Handling Concurrency

Event Versioning Guidelines

This post serves as a guideline for how to handle versioning for messages, specifically in most cases, events. This Event Versioning Guidelines post is in a series related to messaging. You can find the overview in my Message Properties post. Backward Compatible Generally, adding additional properties to an event will not cause a versioning conflict with the event consumer. Meaning if we have a contract that defines the shape of our event, as long as we don’t break that contract, the existing event consumers will be able to process our new event and will ignore the additional properties. Also, if… Read More »Event Versioning Guidelines