polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Merlin <p...@nosphere.org>
Subject Re: [Proposal] Drop EventSourcing for 2.1
Date Fri, 17 Jul 2015 12:21:06 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message