Hi! I have a somewhat newbie question. Since command handler need to know the state of the aggregate anyway, would it a be a bad idea to also snapshot this "prior aggregate state" as metadata in the event it is dispatching?
And I mean... in every event.
@Krule my gut feeling is that it wouldn’t be a great idea
I think there was a similar conversation on the DDD/CQRS mailing list earlier this year
that said, I don’t really use aggregates in my work, and certainly don’t have a “state of aggregate” in lazy event sourcing, so I have limited exposure to this train of thought
thinking if it would make sense to find a new name for es4j
@/all for those interested in chatting about PumpkinDB (see the tweet above: it's a backend for event sourced systems, lazy and not — but with a huge emphasis on indexing as well), you are welcome to https://gitter.im/PumpkinDB/Lobby
@/all also, you might be interested in PumpkinDB/PumpkinDB@9b3c5b3
(btw, es4j is not being abandoned yet — I am usign it in production :) but I do plan to move it over to PumpkinDB backend eventually)
(which means that es4j event/command models will still be usable)