Allow command to accept and pass forward correlation_id?

[davebream]

Assuming the usage of RubyEventStore::CorrelatedCommands, if the flow starts with a command, the correlation_id passed forward to events is always the command's message_id (as seen here).
It seems that passing explicit correlation_id to the command doesn't change this behavior.

I wondered - what if I wanted to have a specific correlation_id that I want to pass to the command?

Let's say I have a command that starts a room check-in process handled by a Process Manager, which subscribes to domain events from multiple bounded contexts:

• Reserving with booking_id in its domain events
• Housekeeping with stay_id in its domain events

How in this scenario, in which booking_id & stay_id should be the same thing as far as PM is concerned, could the stream name for the PM be build without an explicit builder per event/bounded context?

I can use correlation_id for that, but then the stream name includes the command's message_id, and because commands are not persisted, I'm not sure it'd be easy to find and debug if needed. Instead, maybe I could use the core domain aggregate root id as a correlation_id in the command, and then use it to build the stream name?

I'm not sure if this question is valid, it may be that there's just a design problem here 😉

While trying to find opinions on this approach, I came across this EventStore discussion, particularly this comment.

[tomaszwro]

I believe you can easily write a custom version of CorrelatedCommands to behave as you need.

But I wonder if that's the right way to go. The consequence is that you'll have your PM collect events basing on their metadata, which is technical data. For some people it's probably fine, but for some other it might be a no-no :) I'd rather avoid that unless I really need to.

And in your particular example the only thing you gain is that you can avoid a conditional that would take the relevant id from the right attribute. In my experience this is something that you normally do because the ids often come under different names. I never tried to avoid that.

But in general, I think it could be useful to use the commands correlation_id instead of message_id in CorrelatedCommands. I believe this could be useful for cases, where the command itself is a consequence of a preceding event.