Messageinterface, there is a clear distinction between the different types of messages and how they are treated.
NoteNote that all messages are immutable. Storing data in a message actually means creating a new message based on the previous one, with extra information added to it. This guarantees that messages are safe to use in a multi-threaded and distributed environment.
EventMessage. The actual type of Message used depends on the origin of the event. When an event is raised by an aggregate, it is wrapped in a
EventMessage). All other events are wrapped in an
EventMessage. Aside from common
Messageattributes like the unique Identifier an
EventMessagealso contains a timestamp. The
DomainEventMessageadditionally contains the type and identifier of the aggregate that raised the event. It also contains the sequence number of the event in the aggregate's event stream, which allows the order of events to be reproduced.
NoteEven though the
DomainEventMessagecontains a reference to the Aggregate Identifier, you should always include the identifier in the actual Event itself as well. The identifier in the DomainEventMessage is used by the
EventStoreto store events and may not always provide a reliable value for other purposes.
EventMessage. Next to the payload, you can store information in the metadata of an event message. The intent of the metadata is to store additional information about an event that is not primarily intended as business information. Auditing information is a typical example. It allows you to see under which circumstances an Event was raised. Such as the user account that triggered the processing, or the name of the machine that processed the event.
NoteIn general, you should not base business decisions on information in the metadata of event messages. If that is the case, you might have information attached that should really be part of the event itself instead. Metadata is typically used for reporting, auditing and tracing.
NoteAlthough domain events technically indicate a state change, you should try to capture the intention of the state in the event, too. A good practice is to use an abstract implementation of a domain event to capture the fact that certain state has changed, and use a concrete sub-implementation of that abstract class that indicates the intention of the change. For example, you could have an abstract
AddressChangedEvent, and two implementations
AddressCorrectedEventthat capture the intent of the state change. Some listeners don't care about the intent (e.g. database updating event listeners). These will listen to the abstract type. Other listeners do care about the intent and these will listen to the concrete subtypes (e.g. to send an address change confirmation email to the customer).
GenericEventMessageis an implementation that allows you to wrap your Event in a Message. You can use the constructor, or the static
asEventMessage()method. The latter checks whether the given parameter doesn't already implement the
Messageinterface. If so, it is either returned directly (if it implements
EventMessage,) or it returns a new
GenericEventMessageusing the given
Message's payload and Meta Data. If an Event is applied (published) by an Aggregate Axon will automatically wrap the Event in a
DomainEventMessagecontaining the Aggregate's Identifier, Type and Sequence Number.