Event Sourced Process Managers

[Bastian Waidelich]

Hello DDDlers,

I've read Greg Youngs book and I'm particularly intrigued by his description of Event Sourced Process Managers (https://leanpub.com/esversioning/read#leanpub-auto-event-sourced-process-managers).

But I'm missing some pieces here and would be very happy about any feedback:

For example he writes:

"Note that Event Sourced Process Managers tend to only receive and raise events, they will not as example open up a HTTP connection and directly interact with some thing directly"

But now I wonder how these side effects (like dispatching emails, ...) would be implemented.

Is the idea to publish an event along the lines of "EmailDeliveryWasScheduled" and another Event Listener would then actually send the email?

Also, the dummy test example is quite straightforward but I wonder how this PM would actually be work in action.

So if a relevant event was published the PM is reconstituted from all previous events with the same correlation id and the new event is applied? But then the PM events would be published multiple times. Or would you need to differentiate between "replay" and actual event handling?

Also, where would I know to which *stream* to publish the event to?

Thank you in advance,

Bastian

[Daniel Hardt]

As i understand an event sourced PM ist, that you do not replay any events on the PM. The PM itself translate for example an incoming event, into another event, that will be understand by other consumers.

So for example an "UserRegisteredEvent" comes to the PM and the PM creates an "SendRegistrationEMailEvent" that will be stored in the ES of the PM. (Notice here, that i am struggling a little bit, because the SendRegistrationEvent is not in past terms, it's more of a command for a worker process that actually sends the email itself).

So the worker process maybe pulls the events from the EventStore/EventStream of the PM and sends the emails. But it has to remember the events that the worker already processed.

The other way is, that the PM sends a message via service bus to the worker process and the worker process sends an event like "RegistrationEmailSend" back to the PM and the PM stores that event. In that case the worker process for the email sending can not use the event store to get the event.

Or maybe the PM stores both events with a correlation id.

But maybe i am all wrong.

[Bastian Waidelich]

Hi Daniel,

thank you for responding even though you weren't sure!

> As i understand an event sourced PM ist, that you do not replay any events on the PM.

In the book it explicitly states:

"Instead of keeping state off in a state storage the [Event Sourced] Process Manager is rebuilt by replaying the messages it has previously seen".

Either I had an outdated version or Greg has just amended the chapter. But after reading it again I found a response to my question about multiple publishing of previous events:

"Instead of loading up state then pushing a message into the Process Manager the framework builds the Process Manager and pipes its output to /dev/null replays all of the messages the Process Manager has seen previously into the Process Manager. Once the replay has occured the framework then connects the Process Manager to a real publisher (normally this is just handled by an if statement on the publisher). When the actual message is then pushed into the Process Manager any publishes that it does will be considered real publishes."

Regarding side effects:

[...] the PM sends a message via service bus to the worker process and the worker process sends an event like "RegistrationEmailSend" back to the PM and the PM stores that event.

Yes, I guess this is roughly what I suggested above. It would reduce the PM to a state machine with no connection to the outside other then events – and this would make sense to me.

Leaves me with the question about streams, but that's probably an implementation detail.

Thanks again,

Bastian