When I think back at my discussions with Rickard F2F, Event Sourcing in reality wants to record the "cause" and not the "effect", i.e. the business level method that happens is to be recorded and the "effect" of that is replayed through the model each time the entity is retrieved (in case the model changed).
The more I think about that, the more my brain hurts in how an "nice" way this is to be accommodated for in a Zest-natural way. But I think I realized that neither the ES library, nor my previous suggestion here, nor StateListener amendment is the solution. I think the answer is actually an interception capability in Entities+UnitOfWork, which "by default" has the current Entity Store mechanism, but could easily be replaced by an Event Sourcing or Timeseries variant. Would be awesome to have an interactive discussion on a whiteboard over this. Cheers Niclas On Sun, Jul 3, 2016 at 9:19 PM, Paul Merlin <[email protected]> wrote: > Paul Merlin a écrit : > > Another non-core approach we could use for Event Sourcing is to > > implement StateChangeListeners that generate and store state diffs (with > > e.g. json-patch). The same could be done for Timeseries, possibly with > > property/association value granularity. This would still happen out of > > UoWs though. > > Well, no, not as is. We would need to add to EntityState so that it > keeps both the loaded and updated states. > > -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java
