polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kent SĂžlvsten <kent.soelvs...@gmail.com>
Subject Re: Initializable, Invariants in invaluable inspection
Date Sat, 30 Dec 2017 10:10:06 GMT
I believe we missed Initializable on the list.

I have a feeling that the "injection" hooks are somewhat different than the
remaining one - so it remains to be seen whether they can fit in the same
box.

They all seem to be some sort of event - so I wonder whether
ApplicationEvent is the way to go.
We could consider a common event concept, containing both "application" and
"system" events (eg. the ones we are discussing here).
This should possibly be coupled with some scoping - just like some
composites are only available in their own module, something similar could
be possible with events too.

Having opened Pandoras box i am wondering whether the core should actually
be split into 2 parts:

"kernel": basic composites, event system
"DDD": Entity/Value/Service,  UOW, maybe even layers/modules?

where the "DDD" part is implemented on top of the "kernel". This could
probably hint at ways to ekstent the framework with new composite types
(Message, Timeseries) or new ways of persistence (pure relational,
EventStore, CQRS with indexers containing "projections" of the original
data).

But i am probably getting ahead of myself.

But .... Events FTW!


On Tue, Dec 26, 2017 at 2:57 AM, Niclas Hedhman <niclas@hedhman.org> wrote:

> It needs to be executed a bit more than "changed". If itself or any
> aggregated (recursed) entity have changed. I think we originally determined
> "loaded" since perhaps one wants to put in a "last accessed" update before
> the completion.
>
> In any event, yes, this is another "hook" that I would like to make
> generic, so that "UnitOfWorkCallback" is effectively an extension, that is
> "mounted" to the UnitOfWork completion/discard phase. I.e. it should end up
> be possible for you to replace the default UnitOfWorkCallback with your own
> implementation that only calls changed entities.
>
>
> I will open a JIRA issue, and let's see if we can list down all the
> existing hooks available, and identify the meta-hook locations for that.
>
>
> Cheers
>
> On Tue, Dec 26, 2017 at 7:35 AM, Tibor Mlynarik <tibor.mlynarik@gmail.com>
> wrote:
>
> > Merry Christmas to all,
> >
> > > On Dec 25, 2017, at 1:27 AM, Niclas Hedhman <niclas@hedhman.org>
> wrote:
> > >
> > > Merry Christmas everyone,
> > >
> > >
> > > Invariant checking is about ensuring that an Entity Aggregate is never
> > > accessible in a incoherent state. Transactions/UnitOfWork takes care of
> > the
> > > atomicity, but there is no built-in mechanism to ensure that an invalid
> > > state has not occurred "naturally", say, the total allocated container
> > CPU
> > > load isn't higher than the host's available CPU capacity. At the
> moment,
> > > such thing needs to be built in somewhere, and without front-facing
> > > services handling such entities, it is quite easy for developers to
> > > "forget" or "didn't know" such rules.
> > >
> >
> > for Entity invariant checks I found useful hook via UnitOfWorkCallback.
> > The one that is executed per entity instance if entity implements
> > UnitOfWorkCallback.
> > Basically this is how I do cross fields validation for entities.
> > I am thinking if this hook could be optimized and executed only if entity
> > changed, now it is executed for all loaded instances.
> >
> > cheers,
> >
> >         Tibor
>
>
>
>
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>

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