The-Inevitable-Event-Centric-Book
The-Inevitable-Event-Centric-Book copied to clipboard
ylorph
Problem: Define CorrelationId/CausationId patterns for Events
Splitting #25 in multiple issues : Correlation & Causation as Concepts CorrelationId & CausationId as implementation and patterns
One thing I have done is have a wrapper context for each event which stores the things that are about the event (like causation and correlation identifiers, and timestamps, and source etc.) that are not part of the event.
Only the payload of the event may be used by projections but the context is available for diagnostics and routing types of (non business) functionality.
Often that's termed the Envelope; I dont have EIP to hand but I believe that's the source (mentioning as I love the term Context, but always refactor away from it as it's so ... contextual)
Both right ;-)
https://www.enterpriseintegrationpatterns.com/patterns/messaging/EnvelopeWrapper.html
I realised just after I posted that there's a degree of 'do as I say, not as I do' in this. In FsCodec's UnionEncoder based Codec, when packing an event into it's stored form, a context is in play, which one uses together with content from within the event to be able to generate the complete metadata and correlation+causation ids.
However the subtle difference here is that the context is ephemeral and is only used to capture the ingredients for the 'Envelope'. In SqlStreamStore, NewEventMessage vs EventMessage covers the difference between an event that has not yet been persisted (and hence does not have a Version or Position) and one that has. (I name those EventData and TimelineEvent in FsCodec)
Makes me think of what biztalk (!) did with "promoted properties" , they were attributes in the messages that could be used anywhere in the processing pipeline of biztalk (routing, code, ports, ... )