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)
[armetiz (armetiz_), irc.freenode.net] I get a recurring problem using EventSourcing; and I'm wondering if I doing something wrong or If I'm missing pattern
[armetiz (armetiz_), irc.freenode.net] When our aggregate is dealing with a collection; ie: Booking is dealing with a collection of services (VO)
[armetiz (armetiz_), irc.freenode.net] A changed event can occurred; ie: BookingChanged
[armetiz (armetiz_), irc.freenode.net] The BookingChanged is contains the collection of services.
[armetiz (armetiz_), irc.freenode.net] Many time; I need to know the previous version of collection services to compute some differential; the differential can be useful to remove changed/deleted services from a Planning
[armetiz (armetiz_), irc.freenode.net] I can see two solution