DDD，域服务和事件

Question

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:

1. Saving in the domain service of events of the last operation. However, this will violate the principle of stateless for the domain service.
2. Return the list of events from the service method based on the results of the operation (in the return method or in another way, depending on the capabilities of the programming language).

Answer 1

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.