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.
thanks,
Tibor
* 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 <[email protected]> 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 <[email protected]>:
>
>> 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 <[email protected]> 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 <[email protected]>
>>> 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 <[email protected]>:
>>>>
>>>>> 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
>>
>>
