How does process manager keep track of the association between aggregates

Question

Does a process manager make use of correlation-ids or aggregate-specific identifies to keep track of the process it is managing?

To put it more clearly with an example, consider Figure 2 on Saga on Sagas:

First of all, Process Manager sending a OrderConfirmed event is wrong right? I (as a process manager) cannot send events, only issue commands. Or am I wrong?

Second, how does the process manager correlate the OrderCreated, SeatsReserved, PaymentReceived events from different aggregates? Is it correlation id that each aggregate honors (and copies over), or is it specific identifiers (e.g. SeatsReserved has an Order Id that refers to the Order Aggregate)?

Finally, if it is the case of correlation ids, who creates them? Is it the client who issues a command, like PlaceOrder(order_id, correlation_id)? Is it the Aggregate that accepts the command like PlaceOrder(order_id) and then emits OrderCreated(order_id, corr_id) event? Or, is it the process manager (in some way) that is responsible for this? Alternatively, perhaps correlation ids have nothing to do with this?

Thanks for any help.

Answer 1

First I should say that I base my answer on my knowledge, experience and my opinion on how should be doing CQRS on PHP

First of all, Process Manager sending a OrderConfirmed event is wrong right? I (as a process manager) cannot send events, only issue commands. Or am I wrong?

Yes. It is wrong. Only Aggregates raise Domain Events and executes Commands. Perhaps Microsoft forgot to show the MarkOrderAsConfirmed command that is sent to the OrderAggregate.

Second, how does the process manager correlate the OrderCreated, SeatsReserved, PaymentReceived events from different aggregates? Is it correlation id that each aggregate honors (and copies over), or is it specific identifiers (e.g. SeatsReserved has an Order Id that refers to the Order Aggregate)?

I use the IDs of the Aggregates that take part in the process. A correlation ID in this case whould map one-to-one with the ID of the OrderAggregate, it has the same life span.

Finally, if it is the case of correlation ids, who creates them? Is it the client who issues a command, like PlaceOrder(order_id, correlation_id)? Is it the Aggregate that accepts the command like PlaceOrder(order_id) and then emits OrderCreated(order_id, corr_id) event? Or, is it the process manager (in some way) that is responsible for this? Alternatively, perhaps correlation ids have nothing to do with this?

In this case I wouldn't use correlation IDs. I use them for debugging purposes only. In my architecture, in order to eliminate code duplication, correlation IDs are generated by the creator of the command (in the Saga) or by the CommandDispatcher (if this is the first command in the process as are all Commands that are not generated by Sagas) and are stored in the generated events as Metadata.

UPDATE: How to use correlation IDs? You select all events from the event store that have that correlation ID and in this way you can "see" the process.

Answer 2

Highly recommend to get through the original source of the Process Manager design pattern as well as @Vaughn Vernon treatment of the topic in his great book Implementing Domain-Driven Design

In a nutshell, Process Manager deals with multiple processes concurrently via Process instances that it creates when a specific process is initiated. Id of a Process instance is your Correlation Identifier that is part of the payload of every communication (commands/events) in the duration of the process. There is another term for Process instance, that is Process Tracker. The idea is the same.

So in this approach, there is a clear separation of concerns. Every Process Instance is responsible for its own process in terms of its current state, retries, finishing etc. It is a Process Instance that is responsible for emitting ProcessFinished event since it is the "brain".

Another name for Process Manager is Long Running Process. So by definition, it is better be asynchronous.

~ Sergiy

<><

Answer 3

I regard a Process Manager as a first class citizen in my domain. The Id of the process manager instance would typically act as the correlation Id. Since the process manager is a state machine it can, in reality, publish events. Well, I regard Domain Events as different from System Events. The messaging infrastructure relies on System Events. These are the ones that would carry the correlation id and, yes, it would be copied to the relevant messages but this is something that your infrastructure could do automatically. In my Shuttle.Esb service bus I do just that: copy headers and correlation id.

This is why I also regard the process side of things as almost a type of BC in and of itself. It interacts with the various BCs that form part of the process by issuing command and then responding to the relevant events. But on the infrastructure (endpoint) layer I may want to publish an event that states that a particular process has, say, been abandoned or completed or moved from one step to the next.

edit:

In my view the process manager itself is also an aggregate. All commands and events would come from the message handler / application layer in response to what happens in the domain. Any events that do come from the domain would, by their very nature, be domain events and these are not necessarily appropriate for system to system communication. I guess it would be more appropriate to say "on the integration / application layer" than on the infrastructure (endpoint) layer.

All messages are handled in a message handler. That message handler acts as the integration point and has to interact with the domain either directly or through an application layer. My wording may not have made that apparent :)