Can a domain event be emitted without being part of an aggregate state change (DDD)

Question

I would like to know how can a domain event be implemented (in DDD) if it is not a natural result of an aggregate's state change.

I will borrow the example of this post.

So lets say that we need an event like: temperatureWasMeasured which could be a product of some modelling we have done (e.g. in an event storming session).

This event feels like a product of some read action and not an actual state change of some aggregate.

So the question is: Where and how this event could make sense to be emmited?.

We could create an entity or an aggregate, which could have a state to count the number of reads in order to be emmited as a state change. But is this really necessary?

In the resources out there, the definition of the "domain event" does not seem to mention state change, but just as something which has happened in the domain.

So an action of a measurement (in a non quantum mechanical environment ), is considered to be a domain event, like the temperatureWasMeasured event?

It would be great if someone could clarify these questions, since it seems there is no clear answer out there.

Answer 1

Interesting question... I'm trying to get to grips with DDD as well.

Wouldn't you use a Boolean value object within an aggregate to define if its true to false in this case? If temperature was measured or not?

I've always thought you would need to associate any event to an aggregate....

Answer 2

Nice question, my understanding is that domain events should occur when domain state changes and not in a simple query.

In the above example if we want to measure temperature we just query using a repository directly from application layer that has nothing to do with domain, so no domain events should occur.

If someone else is interested in the temperature changes like the example they should probably listen to temperature changed domain event and get their initially state from a query.

If there is a need to know the measurements for this domain a TemperatureMeasure aggregate might be missing from the design that will persist all the measurements and also emit domain events.

Answer 3

Of course I don't know the context, but ** temperatureWasMeasured** feels for me like some kind of action, like I actually need to go through some business logic to measure that temperature (maybe there are few sensors and we want to get average value or something ). If it's a simple read then I would probably return data through some read command + handler and thats all. Maybe If I had more context on which you guys came up with an event like that It would be easier to help. If it was introduced in event storming session then it's something you probably want to trace, but its hard to guess why and by whom.

Maybe it is more like an analytical event for the business? Does not having this event actually affect your business in any way?