Temporal and Watermill solve different problems, or solve problems differently. From a domain perspective, Temporal workflows implement policies and as a result they provide orchestration for the entire process. Nothing stops you from implementing workflows that span through different domains (bounded contexts) though, so if the process is well defined, you can implement it in a single workflow. That gives you the advantage of being able to remediate if any of the steps fail (eg. if the payment fails, the order shouldn't be sent to shipping).
That's not always the case though. Sometimes you need to provide integration points in the system that lets actors outside of a business process to react to events which is when Watermill comes into the picture.
Ultimately, the two can be combined very easily. For example, a Temporal activity can send an event to watermill, or a watermill event can start a new workflow.
As a rule of thumb, try to define your business processes. Everything that fits into a single process should be a workflow. Everything else can be watermill events. This is an interesting topic that's worth exploring, these are just some random thoughts.
I'd also love to hear what @Robert Laszczak thinks. He has extensive knowledge in the DDD field (just read his posts). https://threedots.tech/post/ddd-lite-in-go-introduction/
- https://www.jcheng.org/post/workflow-orchestration-1.0/
- https://www.jcheng.org/post/workflow-orchestration-1.1/
- https://www.jcheng.org/post/workflow-orchestration-1.2/
czeslavo prepared a pretty nice example of Process Manager implementation with Watermill here: https://github.com/czeslavo/process-manager. It's not Saga, but it's pretty similar and with some additions, you may implement saga in a pretty simple way.
Anyway, it would be good to have some tooling in Watermill to support it more out-of-the-box - and this is the long term plan ;-)