polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jiri Jetmar <juergen.jet...@gmail.com>
Subject Re: [Proposal] Drop EventSourcing for 2.1
Date Wed, 15 Jul 2015 07:20:06 GMT
Hi Tibor,

sorry for the late answer, I somehow overlooked your proposal in the flood
of other Qi4j notifications.. :-)

Pls see my comments below :

2015-07-09 3:12 GMT+02:00 Tibor Mlynarik <tibor.mlynarik@gmail.com>:

> Hi Jiri,
>
> pls review my findings about eventsourcing library.
>
> I see whole library as nice building blocks from which one can build
> solution for decoupling between external systems/subsystems.
>

As I understood the idea behind event sourcing, the purpose is to
trigger/generate an event whenever the state of an application has been
mutated.

On can generate events on very different levels in the application, but I
would see the main benefit somewhere very close
to the entities, typicaly directly in the domain model level.


> To support reproducible entity store I am not sure.
>

Yes, the general assumption is when you have something like a event-store
and you are going to resend (or replay) all of the
previously sent domain events one would be able to reproduce 1:1 the entire
domain model state. In the
practical implementation one would need a kind of snapshotting mechanism,
otherwise you are going to resend always
anything from event n(0).

We are using for now the event sourcing mechanism  mostly for
history-keeping purposes. So any mutation
of the domain model generates an event that is routed using a messaging
infrastructure to a dedicated
history-keeping domain model, that uses the same code base (including
versioning) as the original model. The nice
side-effect is that one can use different storage technology for the online
DM and the history-keeping DM.

Cheers,
Jiri



>
> thanks,
>
>         Tibor
>

Thank you Tibor, I think your description is fine. We do not need to
explain the theory behind ES, but the implementation details of Qi4j, what
you did.


>
> * Overview *
> Library supports generating, storing and replying two types of events:
> application-events and domain-events.
>
> Application events are bound to usecase and are produced by execution of
> specific methods ( ones with ApplicationEvent as their first parameter )
> Each application event holds information about usecase, method name and
> json serialized values of method parameters.
>
> Domain events are bound to entity instances and are produced by execution
> of annotated ( see @DomainEvent) method that belongs to EntityComposite.
> Each domain event ( see DomainEventValue) holds information about entity
> type, identity, method name and json serialized values of method parameters.
>
> Both application and domain events are captured during UnitOfWork lifetime
> and are stored in event store after successfully completed UnitOfWork as
> collection together. ( see UnitOfWorkDomainEventsValue and
> TransactionApplicationEvents).
>
> There is support for replying events. When events are replied the same
> code is executed but no new events are generated.
>
> Event store supports indexed and streamed access to events feed. There is
> in-memory and JDBM backed implementation.
> For remote access to feed there is eventsourcing-rest library that exposes
> events as Atom feeds.
>
> There are helper classes that enables a service to easily track event
> feed, and
> for domain events there is event router that allow specify
> specification->receiver routes.
>
> * Not not so good parts, limitations *
>
> Application events part seems to be not finished.
> ApplicationEventFactoryService has wrong concern associated.
> There is only abstract base for event store ( thought should be easy
> copied from domain events). And missing tests.
>
> Parameters serialization and deserialization seems to be not symmetric in
> supported types.
>
> There is support for events reply , but there seems to be those
> limitations for domain events:
>
> - all entity mutations has to go via annotated methods, otherwise one
> cannot rebuild entity state fully
> - no support for entity removal
> - no suport for entity properties constraints ( blank entity instance is
> created when it's id is not existing yet)
> - limited support for parameter types (?)
>
> as for application events mapping from usecase name to target instance has
> to be managed somehow.
>
> * Blog post + slides *
>
> [1]
> http://www.jroller.com/rickard/entry/application_event_distribution_through_rest
> [2] http://www.slideshare.net/Rickardberg/eventsourcing-applied
>
>
> On Jul 8, 2015, at 1:34 PM, Jiri Jetmar <juergen.jetmar@gmail.com> wrote:
>
> > Hi Tibor,
> >
> > I;m also not an expert of the ES lib, but evtl. I would be able to
> > review/give a feedback
> > an your proposal.
> >
> > Cheers,
> > Jiri
> >
> > 2015-07-08 13:05 GMT+02:00 Tibor Mlynarik <tibor.mlynarik@gmail.com>:
> >
> >> It takes me some time to understand this lib ( as I am not user of it )
> ,
> >> but hopefully I will come with some docs later today.
> >>
> >> cheers,
> >>
> >>        Tibor
> >>
> >> On Jul 8, 2015, at 12:57 PM, Niclas Hedhman <niclas@hedhman.org> wrote:
> >>
> >>> Ok, I withdraw this suggestion then. Hopes move to Tibor to help with
> >> some
> >>> basic docs. Any other volunteer is appreciated.
> >>>
> >>> On Wed, Jul 8, 2015 at 1:29 PM, Jiri Jetmar <juergen.jetmar@gmail.com>
> >>> wrote:
> >>>
> >>>> Hi Niclas,
> >>>>
> >>>> we are using it on the DM/Entity level. Any C(R)UD interaction uses
> >> Domain
> >>>> Events. In fact the Entity i.) triggers the Event and consumes it at
> the
> >>>> same time in order to mutate its state.
> >>>>
> >>>> So pls let it in.. :) The Domain Event Library is indeed not perfect,
> >> but
> >>>> at least for us robust enough to be used.
> >>>>
> >>>> Thank you.
> >>>>
> >>>> Cheers,
> >>>> Jiri
> >>>>
> >>>> 2015-07-08 11:57 GMT+02:00 Niclas Hedhman <niclas@hedhman.org>:
> >>>>
> >>>>> I have briefly reviewed the eventsourcing codebase, and the immediate
> >>>>> feeling I got was; "This should be with Java 8 Stream API".
> >>>>>
> >>>>> So, I think we should simply mothball (drop from settings.gradle)
the
> >>>>> eventsourcing libraries and resurrect it somewhere in 3.x when we
> have
> >>>> Java
> >>>>> 8 available.
> >>>>>
> >>>>> If anyone is depending on this library (I assume that StreamFlow
uses
> >> its
> >>>>> own implementation, and still depend on Qi4j 1.4.x), then raise
an
> >>>>> objection (together with some docs ;-) )
> >>>>>
> >>>>>
> >>>>> Cheers
> >>>>> --
> >>>>> Niclas Hedhman, Software Developer
> >>>>> http://zest.apache.org - New Energy for Java
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Niclas Hedhman, Software Developer
> >>> http://zest.apache.org - New Energy for Java
> >>
> >>
>
>

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