When, where and how to create Summary Events about php-ddd HOT 3 OPEN

The state of the projection can be a separate layer from read and write models. In this case it would be a segregated event layer. In our applications we do this a lot when process summaries need to aggregate over multiple steps. We then store the aggregated state in a separate store/table.

from php-ddd.

If I understand correctly the problem is that event handler that is supposted to publish "summary event",
is called before corresponding read model is regenerated and both listen on the same event.

If you will run publishing summary event asynchronously and regenerating read model synchronously, then you should avoid the problem.
This will work just as indexes in database. When columns which are indexed are modified, then index (read model) is synchronously updated.

from php-ddd.

Thanks for your feedback @dgafka . We prefer to create our read models asynch and run the projections as long-running processes.

I added approach 3. We load the read model when a certain event has happened. It does not matter if the read model already has the current data. We take it as it is. But we use the current data from the event and simply overwrite it in the read model.

Then we publish an summary event.

A consumer takes the event and acts as a process manager. It sends commands that change the state on an aggregate that publishes the events to a segregated event layer. As suggested by @tPl0ch .

This seems to work far so fine.

from php-ddd.