Read models: access to previous projection state

[TomKaltz]

Currently projection functions aren't given the previous state, like aggregates "on" handlers get. This can sometimes pose a problem when you want to keep your event data slim and only carry domain intent without extraneous data needed to calculate the next read model state. Since we have guaranteed ordering of event processing, should the framework feed the previous state of the projection to the projection event processor by default?

One way to overcome this is to query for the previous state of the same projection when handling the event but it feels wrong. I believe this to be a correct way of handling the issue but it also feels verbose to do so. Am I thinking about this wrong?

[Rotorsoft]

I have always considered projections to be an experimental feature, given the challenges of finding a good generalization here. The first version injected the current state to the handlers, but I wasn't super happy with it. Needs more work for sure.

[TomKaltz]

What did you dislike about that approach in the first version?

[Rotorsoft]

It didn't feel generic enough, and I didn't want to recreate an ORM framework. In my opinion, aggregates and projections should be pretty close in terms of interfaces and implementations; we just need to find an efficient implementation.