Hi ,
I have created pull request with basic eventsourcing docs :
https://github.com/apache/zest-qi4j/pull/1
Assembler, MemoryApplicationEventStoreService and application events test was
added also.
cheers,
Tibor
On Jul 17, 2015, at 2:21 PM, Paul Merlin <p...@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.mlyna...@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
>
