polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Philosophy behind Identity
Date Sun, 03 Jul 2016 14:01:28 GMT
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 <paul@nosphere.org> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message