Do we need ProcessManager / Saga in the first implementation?

[dfeyer]

Just a bookmark issue, to not forget this ;)

Personally I hate Saga, and ProcessManager describe more clearly what it is. I think that we can avoid the concept in the first implementation, but at some point I feel that we will need something in the area.

[dfeyer]

Related to this discussion #3 (comment)

[bwaidelich]

I don't think that we'd need any specific support for this as ProcessManagers can be modeled just like aggregates AFAIK.

[Akii]

I'm also against implementing them at this point. Especially long running (persisted) process managers are tricky.

I think the difference between a process manager and an aggregate is that the latter actually issues commands and waits for resulting events from other aggregates. But I'm not completely into that topic.

[bwaidelich]

I think the difference between a process manager and an aggregate is that the latter actually issues commands and waits for resulting events from other aggregates

Exactly my gut feeling but I also haven't really worked with them yet.

BTW: My point was not that PM == AR (even though that could be argued) but that we can use the already existing mechanics for those

[bwaidelich]

Chatting about this in the #guild-cqrs channel I realized that there is a missing mechanism in order to work with PMs (it's not exactly related to PM/Saga but something we'd need anyways IMO):
Currently aggregates can only reconstitute their state from own events. For a PM we'd need a mechanism to listen only to a specific set of events.
With the current mechanism we have for EventListeners we can already "pro-actively" determine the event type that is handled by a particular listener. For a PM we'd probably need a more advanced mechanism so that the system can determine where to forward a certain event to. I.E. an OrderProcessManager instance might only be interested in events of a specific Order. See https://github.com/neos/Neos.EventStore/issues/1 for a related requirement.

[albe]

So one thing I found is that there is some difference between the Saga concept in CQRS (long running transaction) and what I personally see as ProcessManager:

A ProcessManager for me just defines a reaction (normally a new Command, but could IMO also be an Event - more later) to a specific series of Events that have happened, without any implications to transactional behaviour. The transactional behaviour would mean that the events in the process either all happen, or none at all. I think this is not required in a lot (if not most) cases and that actually leads to making ProcessManagers hard to implement.

Also in most writing one finds about this concept, a ProcessManager dispatches a new Command only. However, a Command is just a Message that implicates that it can be rejected, while an Event is also a Message but one that just can't be rejected. An Event is a fact, deal with it or ignore it.
I find there are use-cases where a process will not trigger something that is only possibly done, but a process can also just model a very fixed thing that will inevitably happen if a series of things happened before. In the simplest case, such a process could just model a transformation/translation of a single event (for example between two BCs).

So a ProcessManager signature for me looks like: (Event[]) -> Event|Command

On the implementation side, it would just be an EventListenerInterface that has a CommandBus (there's the use-case for the CommandBus ;)) and an EventBus injected and available for sending messages to the system.
The events the ProcessManager emits should be considered transient, so are not persisted in the EventStore (otherwise you should just make it an Aggregate or command another Aggregate). For replay, the ProcessManagers are registered, so they will still take part (and therefore should not contain side effects, see #24).
Of course, this opens up the ProcessManager for "altering history" in the sense of any changes to the events they emit will change the outcome of replaying the history.

What do you think? Is this a reasonable concept of a ProcessManager or am I trying to make the ProcessManager something that it isn't?

[bwaidelich]

I don't think that we need to implement anything special for Sagas/ProcessManagers.
As @albe said, it's just a EventListener that can have state and access to CommandHandlers.

See #24 for a related discussion