Situation:
To work with domain events, Jimmy Bogart proposed a method for storing events in aggregates.
This, from my point of view, is a very convenient approach. However, what about the case of a domain event in the domain service?
Domain Service should not have a state (stateless). In this case, in theory, the IDispatcher event dispatcher must be injected into the constructor of such a service.
Question:
To avoid introducing into the domain service of the event dispatcher, the suggested alternative approaches are correct:
Note: that post was written about five years ago. You may want to review his more recent (and more detailed): Life Beyond Distributed Transactions: An Apostate's Implementation
Domain Service should not have a state
Right - and for this reason, it is very suspicious that you would want to assign responsibility for domain events in the domain service.
You might use a domain service to calculate events for the aggregate, but the storage would still belong to the aggregate structure itself. So that would probably look like a function (or, if you prefer, a method on the domain service) that accepts some arguments provided by the aggregate and returns events.