Thank you for your response Tim.
I totally glossed over the fact that if some service subscribes to an event then it obviously cares about the occurence of that event. My mistake.
What I think I was missing was that whilst Sales is interested in knowing when Finance has finished processing an order payment, with a good or bad outcome, it doesn’t care when the processing occurs or is triggered. Sales should assume Finance will do what it needs to do, whether that is triggered by a pivotal event like OrderPlaced or something else. Bottom line is, Finance won’t be told when to start processing the payment by some other service. It decides for itself.
As for commands only being used inter-service rather than cross-service I agree for sure. I’ve always had problems grasping this in the past as for a long time I never really understood the concept of a service as a logical thing that can have many components that indeed can talk to each other, and that this doesn’t necessarily contribute 1-to-1 to deployment architecture.
I’ve followed some of Udi’s course material and also View Model Composition strategies (shout out to Mauro Servienti for his work in this area) and it was enlightening in terms of thinking about decoupling the responsibility of who owns what. For example, whilst a mobile app backend or a webapp might want to tell other services about some user action, it doesn’t own the “how” it is achieved or “which” services might handle the request or message.
If I may, can I ask about your thoughts on sagas publishing events as opposed to only sending commands? I’ve followed a pattern comprised of the following implementation “rules” in terms of NServiceBus and handlers in general:
- Command handlers can make domain state changes and publish an event - for eventual consistency.
- Command handlers can call an idempotent external API and publish an event.
- Command handlers cannot change domain state, call an external API and publish an event.
- Event handlers can only send commands.
- Sagas can only by triggered by and handle events.
- Sagas can only send commands or reply to sender.
With my rules it implies a saga can only orchestrate activity based upon event information only. However sagas can have state and if that state changes due to handling an event in the saga you could argue that it’s perfectly valid for the saga to publish this fact, rather than sending a command that perhaps does nothing other than publish that same event.
I’m tending towards a don’t-complicate-things approach and allow the saga to publish events in the cases where no other side-effect is required. Is this okay or am I’m missing something?