polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tibor Mlynarik <tibor.mlyna...@gmail.com>
Subject Re: [Proposal] Drop EventSourcing for 2.1
Date Thu, 09 Jul 2015 01:12:37 GMT
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.
To support reproducible entity store I am not sure.



* 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

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

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