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 Fri, 17 Jul 2015 16:07:38 GMT
Jiri thanks for review.
I am going to make docs in proper places.

cheers,

	Tibor


On Jul 17, 2015, at 2:21 PM, Paul Merlin <paul@nosphere.org> wrote:

> Tibor, Jiri,
> 
> Thanks for putting effort into this.
> 
> A bit more is needed to actually include the documentation in Zest.
> For example, some assembly guidance would be a huge plus.
> 
> For now the non-existent documentation is split across:
> 
> - libraries/eventsourcing/src/docs/eventsourcing.txt
> - libraries/eventsourcing-jdbm/src/docs/eventsourcing-jdbm.txt
> - libraries/eventsourcing-rest/src/docs/eventsourcing-rest.txt
> 
> But, like it's done for SQL libraries (libraries/sql-*), we can put the
> EventSourcing documentation in a single file/page. See
> libraries/sql/src/docs/sql.txt for a sample.
> 
> This would mean putting your documentation covering the three
> eventsourcing librairies in
> `libraries/eventsourcing/src/docs/eventsourcing.txt` removing the two
> other files and their inclusion in
> `manual/src/docs/userguide/libraries.txt`.
> 
> Or, we can keep the three files/pages, whatever suits your contribution
> mood :)
> 
> 
> Ping me if you need anything.
> 
> Cheers
> 
> /Paul
> 
> 
> Jiri Jetmar a écrit :
>> 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
> 


Mime
View raw message