polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Merlin <p...@nosphere.org>
Subject Re: Philosophy behind Identity
Date Sun, 03 Jul 2016 13:14:28 GMT
Niclas Hedhman a écrit :
> On Sat, Jul 2, 2016 at 11:18 PM, Paul Merlin <paul@nosphere.org> wrote:
>> On 2016-06-22 14:45 (+0200), Niclas Hedhman wrote:
>>> Entity == "Identity with Value property",
>>> versus DTO == "Value with Identity property"
>> It makes sense in the DDD mindset but blurs the very definition of
>> entities.
>> You can persist entities and navigate through their relationships but
>> you can't do that with Values.
> Well, we allow navigation of Values that has Entity references if there is
> an active/valid UnitOfWork.

Ah, right!

> The underlying driver for me to even visit this basic concept (since Zest
> 0,1), is that I am looking at direct timeseries support, which is a
> specialized case of event sourcing, and also touches on Aggregates,
> something that we never managed to solve although it was discussed at
> length in 2008.
> Right now I am leaning towards redefinition of entities to become;
> Entity = Identity + Value + Invariant Constraints + Metadata
> Metadata are things like "lastModified", "version", "composite types" and
> other
> Pros that I see with this model;
>   a. toValue and toEntity conversion becomes magnitudes faster.
>   b. Aggregate support is stronger
>   c. Historical snapshots becomes trivial to support.

Yeah, it was discussed several times in the past.
Sounds good!
Invariant constraints are to be enforced at UoW completion, correct?

> The Cons;
>   a. Event Sourcing is not expressed directly in model.
>   b. Timeseries doesn't really fit, since it wants "values within
> timerange" views.


For both Event Sourcing and Timeseries, what level of granularity do we

The existing, non-core-integrated, event-sourcing library makes each
property/association change an event, aggregated by UoW, stored out of UoW.

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.

I've the gut feeling that modelling Event Sourcing in core would mean
changing the EntityStore story and API.

We could push this forward step by step. Maybe aim at a proper entity
model (and serialization) in 3.x and core event sourcing/timeseries in 4.x?

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